April 2019 - openstack-discuss - lists.openstack.org

[telemetry][panko][ceilometer][aodh][zuul] Replace telemetry-tox-py37 with openstack-python37-jobs
by Trinh Nguyen 16 Apr '19

16 Apr '19

Hi team, I would love to replace telemetry-tox-py37 with openstack-python37-jobs since the only main difference is the nodeset [1]. If you know any reason to keep it that way, please let me know. Yours, [1] https://github.com/openstack/ceilometer/blob/master/.zuul.yaml#L47 -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 2

Re: [placement][nova][ptg] resource provider affinity
by Alex Xu 16 Apr '19

16 Apr '19

we miss the maillist address, sorry I start that one....add it back. Alex Xu <soulxu(a)gmail.com> 于2019年4月16日周二上午7:16写道： > > > Sean Mooney <smooney(a)redhat.com> 于2019年4月16日周二上午2:27写道： > >> On Mon, 2019-04-15 at 23:16 +0800, Alex Xu wrote: >> > >> > > >> > > ?resources=DISK_GB& >> > > resources1=VCPU:2,MEMORY_MB:128& >> > > resources1.1=VF:1& >> > > resources2=VCPU:2,MEMORY_MB:128& >> > > resources2.1=VF:1& >> > > group_policy=isolate >> > > >> > > Is it the case you talking about? Sorry, I probably didn't get what >> you >> > > mean about changing grouping and group policies. Is there any >> conflict case >> > > from you vision? >> > > >> > >> > Sorry, I miss read your case. It should be >> > >> > ?resources=DISK_GB:10,VF:1& >> > resources1=VCPU:2,MEMORY_MB:128& >> > resources2=VCPU:2,MEMORY_MB:128& >> > group_policy=isolate >> > >> > VF may get from any RP in the whole tree. >> no that wont work because it would require the disk_GB and the VF to come >> form the same resouce provideer. >> so you would have to do >> > > No, that isn't un-numbered resources meaning. DISK_GB and VF are in > un-numbered request group. It may get from any RP in the whole tree, and > needn't to be same resource provider. > > > http://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/gra… > "The semantic for the (single) un-numbered grouping is unchanged. That is, > it may still return results from different RPs in the same tree (or, when > “shared” is fully implemented, the same aggregate)." > > >> ?resources=DISK_GB:10& >> resources1=VCPU:2,MEMORY_MB:128& >> resources2=VCPU:2,MEMORY_MB:128& >> resoucees3=VF:1 >> group_policy=isolate >> >> the issue aries if i want 2 VF >> >> do you do >> ?resources=DISK_GB:10& >> resources1=VCPU:2,MEMORY_MB:128& >> resources2=VCPU:2,MEMORY_MB:128& >> resoucees3=VF:1 >> resoucees4=VF:1 >> group_policy=isolate >> >> or >> ?resources=DISK_GB:10& >> resources1=VCPU:2,MEMORY_MB:128& >> resources2=VCPU:2,MEMORY_MB:128& >> resoucees3=VF:2 >> group_policy=isolate >> >> or >> ?resources=DISK_GB:10& >> resources1=VCPU:2,MEMORY_MB:128& >> resources2=VCPU:2,MEMORY_MB:128& >> resoucees3=VF:1 >> resoucees4=VF:1 >> grou >> p_policy=None >> >> i woudl say the last one is the most correct from the neutorn point of >> view >> however we lose guarentee teh cpu and ram come form different numa node >> the first option forces the vif to be form different RP and the second >> requires them to >> be form the same RPs >> >> what you really want is >> ?resources=DISK_GB:10& >> resources1=VCPU:2,MEMORY_MB:128& >> resources2=VCPU:2,MEMORY_MB:128& >> resoucees3=VF:1 >> resoucees4=VF:1 >> grou >> p_policy=isolate;none:3,4 >> >> i.e. the vfs can come form any RP in the tree but resouce group 1 an 2 >> need to be isolated. >> or said another way by default each resouce group is isolated but resouce >> groups 3 and 4 have policy none. >> >> > >> > >> > >> >>

1 0

[cinder][emc-unisphere]Need help: Some exception raise when using IPV6 to connect the EMC unisphere.
by hao wang 15 Apr '19

15 Apr '19

hi guys: Now I was using unisphere 4.4 as cinder's backend with ipv6 address. But there is an exception when I try to start the cinder volume: 2019-04-15 17:14:25.832 25795 DEBUG storops.connection.client [req-b86ea626-dcd5-4d76-9186-4f2dc902f244 - - - - -] REQ URL: [GET] https://[2019:c:0:0:0:0:0:220]:443/api/types/basicSystemInfo?compact=True&f…, TIME: 0.019809961319, RESP CODE: 400 log_response /usr/local/lib/python2.7/site-packages/storops/connection/client.py:186 2019-04-15 17:14:25.833 25795 DEBUG storops.connection.client [req-b86ea626-dcd5-4d76-9186-4f2dc902f244 - - - - -] RESP BODY: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> </p> </body></html> _debug_print_json /usr/local/lib/python2.7/site-packages/storops/connection/client.py:179 I have configured the ipv6 and ipv4 address in unisphere and it connected well with my cinder volume node. When I switched the unify driver to ipv4 san ip in cinder.conf, it worked well.... So I really didn't get where is wrong. Could guys help me out here? thanks.

2 1

Disabling SSLv3, TLSv1.0 and TLSv1.1 in nova-novncproxy?
by Ricardo J. Barberis 15 Apr '19

15 Apr '19

Hello list, I've been tasked with disabling SSLv3, TLSv1.0 and TLSv1.1 in all of our public endpoints (not only OpenStack) and I'm having trouble finding where does nova-novncproxy sets which protocols to use. I have nova-novncproxy installed in 2 servers, one CentOS 6.10 (python 2.6) tied to an IceHouse installation, the other a CentOS 7 (python 2.7) tied to a Queens installation. Software versions: [root@vnc01 ~] # rpm -qa \*nova\* \*vnc\* | sort novnc-0.4-8.el6.noarch openstack-nova-common-2014.1.5-1.el6.noarch openstack-nova-novncproxy-2014.1.5-1.el6.noarch python-nova-2014.1.5-1.el6.noarch python-novaclient-2.17.0-2.el6.noarch [root@vnc02 ~] # rpm -qa \*nova\* \*vnc\* | sort novnc-0.5.1-2.el7.noarch openstack-nova-common-17.0.9-1.el7.noarch openstack-nova-novncproxy-17.0.9-1.el7.noarch python-nova-17.0.9-1.el7.noarch python2-novaclient-10.1.0-1.el7.noarch Any pointers will be appreciated. BTW, I also tried proxying them with nginx but in that case the vnc console doesn't work. I didn't try too hard to debug it, though. Thanks, -- Ricardo J. Barberis Usuario Linux Nº 250625: http://counter.li.org/ Usuario LFS Nº 5121: http://www.linuxfromscratch.org/ Senior SysAdmin / IT Architect - www.DonWeb.com

2 2

[neutron] Bug deputy report - week 8.04 - 15.04
by Slawomir Kaplonski 15 Apr '19

15 Apr '19

Hi, I was on bug deputy last week. Below is summary of bugs reported this week. There is couple of bugs which require help from the team: High: https://bugs.launchpad.net/neutron/+bug/1824299 - Race condition during init may lead to neutron server malfunction - marked as High, there is no volunteer for this one, someone needs to take a look into it. https://bugs.launchpad.net/neutron/+bug/1824571 - l3agent can't create router if there are multiple external networks - I confirmed it today, it looks that when there is more than one network marked as „external” than router can’t be created properly. It looks that it is quite serious one and someone from L3 sub team should take a look into it Medium: https://bugs.launchpad.net/neutron/+bug/1824799 - neutron dhcp agent looks for external pid unexpectedly - volunteer for this one is needed, if there will be no any I will take a look for this bug, Low: https://bugs.launchpad.net/neutron/+bug/1824788 - [DOCS] installed neutron, but no provider network exists - volunteer needed, Also I would like to ask team about this one: https://bugs.launchpad.net/neutron/+bug/1818682 - issue in keepalived 1.2.24 - user asked about list of software (and versions) compatible with neutron. Do we have anything like that? And now list of all other bugs from this week: Critical https://bugs.launchpad.net/neutron/+bug/1823865 - [neutron][networking-ovn] The function provider_network_attribute_updates_supported is breaking networking-ovn gate - marked as critical because it broke gate for stadium project - fix already released, thx Rodolfo. High https://bugs.launchpad.net/kolla/+bug/1823818 - Memory leak in some neutron agents - set to high but in fact this issue is in openvswitch, not in neutron agents directly, I marked it as invalid in neutron as fix is in openvswitch already, https://bugs.launchpad.net/neutron/+bug/1824095 - Fullstack job broken in stable/stein branch - I set to High and not to urgent because fullstack job is non-voting in stein currently so it’s not blocking gate completely - fix already merged (https://review.openstack.org/#/c/651458/) - thx again Rodolfo :) https://bugs.launchpad.net/neutron/+bug/1824138 - Fullstack QoS tests should not handle other tests port events - marked as High because it’s causing gate failures - fix already proposed by Rodolfo (again): https://review.openstack.org/#/c/651523/ - please review it, Medium https://bugs.launchpad.net/neutron/+bug/1823798 - rfp and fpr interfaces not updated after changing network MTU - fixed by Brian already - thx Brian, https://bugs.launchpad.net/neutron/+bug/1824178 - SQLAlchemy broke association proxy into a descriptor + per-class accessor - fix proposed by Rodolfo (is anyone else except Rodolfo working in Neutron now? :P) - https://review.openstack.org/#/c/651584/ https://bugs.launchpad.net/neutron/+bug/1824346 - Check in "_update_segmentation_id" that the mech_driver has an agent - fix proposed by (what a surprise) … Rodolfo - https://review.openstack.org/#/c/651878/ https://bugs.launchpad.net/neutron/+bug/1824504 - arp responder will be created for a vlan port when port ip changed - fix proposed already https://review.openstack.org/652043 https://bugs.launchpad.net/neutron/+bug/1824566 - DVR-Nexthop static routes are not getting configured in FIP Namespace when disassociating and reassociating a FloatingIP in Ocata - only for Ocata, looks that it don’t affects newer releases, fix proposed https://review.openstack.org/652122 Low https://bugs.launchpad.net/neutron/+bug/1823716 - (DOCS) url --> endpoint_template in Install and configure controller node in neutron section of nova.conf - there is volunteer for this one already assigned RFE * https://bugs.launchpad.net/neutron/+bug/1823633 - [RFE] L3 - netfilter Contrack Helper Support - already approved by drivers team (that was fast) Others https://bugs.launchpad.net/neutron/+bug/1824107 - marked as duplicate of https://bugs.launchpad.net/neutron/+bug/1808112 So the winner of "bug fixer of the week” title is definitely Rodolfo :) — Slawek Kaplonski Senior software engineer Red Hat

1 1

[kolla] No IRC meeting on 17th April
by Mark Goddard 15 Apr '19

15 Apr '19

Hi, I'm cancelling this weeks IRC meeting because I'm on vacation from tomorrow until 24th April and nobody offered to chair. Please continue to coordinate in #openstack-kolla. Focus should be on testing the upcoming Stein release and fixing bugs. Thanks, Mark

1 0

[kayobe] No IRC meeting on 29th April
by Mark Goddard 15 Apr '19

15 Apr '19

Hi, We'll cancel the next IRC meeting due to the OpenStack summit. Please bring up any items in #openstack-kayobe on an ad-hoc basis. Thanks, Mark

1 0

Re: [Release-job-failures] release-post job for openstack/releases failed
by Thierry Carrez 15 Apr '19

15 Apr '19

zuul(a)openstack.org wrote: > Build failed. > > - tag-releases http://logs.openstack.org/80/804d609460e6b165e0549e6759b1d0ee277a970a/relea… : TIMED_OUT in 31m 08s > - publish-tox-docs-static publish-tox-docs-static : SKIPPED During release-post processing of the ocata-em tagging change [1], we hit a job timeout[2]. It went as far down as sahara.yaml, where it successfully tagged sahara, sahara-dashboard, sahara-extra, sahara-image-elements, before hitting the timeout. So it did not tackle searchlight-ui and the 28 other deliverables after that. [1] https://git.openstack.org/cgit/openstack/releases/commit/?id=804d609460e6b1… [2] http://logs.openstack.org/80/804d609460e6b165e0549e6759b1d0ee277a970a/relea… -- Thierry Carrez (ttx)

2 1

Pike: "Observer" or "read-only" admin access?
by Ken D'Ambrosio 15 Apr '19

15 Apr '19

Hi, all. Beginning to roll out a newer-than-what-we-had OpenStack release -- likely to be Pike, "For reasons." (Which is still *worlds* newer than Juno, where we are.) And I've been asked if there's such a thing as an account (or ACL) that allows a user to read everything, but write nothing. Googling, I see mention of such things -- but nothing really firm. Does it exist? Is it in Pike (or more recent releases)? If it doesn't exist, is there a graceful way to make it happen, anyway? Thanks! -Ken

3 2

[Cinder] Odd Volume and Volume Snapshot Dependencies
by Jeremy Houser 15 Apr '19

15 Apr '19

Currently running python-openstackclient functional tests against an openstack deployment. Ran into some odd functionality whilst manipulating volumes and snapshots in openstack via cli and gui. I create a volume, create a snapshot of that volume, and then create a volume from that snapshot. I can't delete the snapshot until I delete the volume that I spawned using that snapshot. I understand the dependency of "can't delete a volume while a snapshot dependent on that volume is deleted first" but why can't a volume snapshot be deleted when volumes are spawned from it? Is this intentional? I am working with Cinder 3.27. Jeremy

2 1

[sig][upgrades] IRC meeting minutes 15th April 2019 @ 0900 UTC
by James Page 15 Apr '19

15 Apr '19

Hi All Minutes from this mornings Upgrades SIG meeting: http://eavesdrop.openstack.org/meetings/upgrades_sig/2019/upgrades_sig.2019… One question was asked about longer term running of mixed version clouds, which although not ideal might be a reality due to management of change slots for upgrades etc... If anyone has experience of this situation it would be nice to share! Reminder that the second Upgrades SIG IRC meeting is scheduled for 1600 UTC today, covering those in US timezones. Thanks James

1 0

[placement][ironic][blazar][ptg] "direct baremetal reservations" with ironic+blazar
by Chris Dent 15 Apr '19

15 Apr '19

The etherpad [1] doesn't have any additional notes besides the topic but the general questions are: * Do people want to do baremetal reservations with some combination of Ironic, Placement and Blazar, now or ever? * What about Ironic and Placement, sans-Nova? * If so, what would need to happen to make those things possible? Based on my observations at the recent OpenInfra Days UK, I'd say there's definitely an underserved need for this kind of functionality. From the Placement side of things I would guess there's little that would need to be done; it's more a matter of getting other pieces and parts getting data in and out of Placement. Discuss... [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 5

[chef] Renaming the Chef OpenStack project
by Jens Harbott 15 Apr '19

15 Apr '19

In order to clean up some inconsistencies in project naming I have submitted a request to the TC to update the name of the Chef OpenStack project to "openstack-chef"[0]. The reasoning for this is twofold: a) It brings the name into line with other deployment projects like "OpenStack Ansible" and "OpenStack Charms". b) In addition there are sometimes drawbacks when there is an embedded space in the name, so I opted for the hyphenated version. Together with lowercasing everything this also has the effect to match: - The name of our central repository - The name of our IRC channel - Our project name on Launchpad Please let me know whether you agree with this change or if there are any objections. [0] https://review.openstack.org/648356

4 4

OpenStack Newton MessagingTimeouts for os-getVNCConsole
by Teckelmann, Ralf, NMU-OIP 15 Apr '19

15 Apr '19

Hello everyone, My colleagues and I are maintaining a newton-based openstack installation. We use linux containers on ubuntu 16.04 nodes for service separation and HA. After switiching to HTTPS + Domain for all our Endpoints (was http and IP-based before) we face the problem of MessagingTimeout for os-getVNCConsole-Requests. In (1) you can find the Stack Trace we get on a request for VNCConsole Access. We have traced this down to the point were we actually tcpdumped the communication and we can see the response message arriving back(2). The timeline looks like: - 13:37:22 GMT - Sending request via nova get-vnc-console a29f9b95-055e-4f30-8a30-ac0bcde32dd1 novnc - xx:xx:xx - Arrival at RabbitMQ - 14:37:22.806 CET - Compute Hosts gets the request - 14:37:22.810 CET - Compute Hosts sends response to RabbitMQ - xx:xx:xx - Response enters RabbitMQ - 14:37:22.812 CET - tcpdumped response at the interface of the control node where the nova cloud controller resides on, who send the request - 13:38:22.826 UTC - Timeout /var/log/nova/nova-api-os-compute.log It could be expected, that the response messages actually arrives at the requesting process. However, I can not narrow it down to exactly this point, because - I can't tcpdump in an lxd container - The system is highly productive and possibilities for debugging are limited - We have no other problems with this installation in any matter, so a global problem can be excluded We are actually not sure if the mismatch in timezones acutally leads to a problem. The fact, that our problem is isolated and all other communication runs fine makes us believe it's not. Taking the returned "access_url" from the sniffed package(2) and e.g. pasting it to a browser, we get the Standard VNC Console Screen. This shows the general communication via port 6080 is also possible. Nonetheless, even doing the as soon as the package was sniffed I never got an actual novnc-session to the VM. We are stuck at this point, because we simply can't completely understand the python code :( I hope you can ask some helping questions to get us a step further. You can find a list of our current dpkg and pip packages in (3). Questions we are currently able formulate are: - Is there any communication taking place besides the regular ports (8774, 6080, 5672) in the process? - are the generated access_urls verified in any way after receiving the response message from RabbitMQ, which could lead to an exception being thrown? - are we looking at the right communication flow (https://docs.openstack.org/nova/pike/_images/SCH_5009_V00_NUAC-VNC_OpenStac…, there is no one for newton!?) at all? Best regards Ralf Teckelmann (1) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py", line 338, in wrapped 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 73, in wrapper 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/remote_consoles.py", line 56, in get_vnc_console 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions console_type) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 157, in wrapped 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return function(self, context, instance, *args, **kwargs) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 3283, in get_vnc_console 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions access_url=connect_info['access_url']) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/consoleauth/rpcapi.py", line 89, in authorize_console 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions return cctxt.call(ctxt, 'authorize_console', **msg_args) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 169, in call 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions retry=self.retry) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 97, in _send 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions timeout=timeout, retry=retry) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 464, in send 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions retry=retry) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 453, in _send 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions result = self._waiter.wait(msg_id, timeout) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 336, in wait 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions message = self.waiters.get(msg_id, timeout=timeout) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 238, in get 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions 'to message ID %s' % msg_id) 2019-03-29 13:38:22.826 18711 ERROR nova.api.openstack.extensions MessagingTimeout: Timed out waiting for a reply to message ID bd66ed7b4fe44f5c8527573081379639 (2) IP addresses are obfuscate in order to meet company regulation 2019-03-29 14:37:22.812563 IP (tos 0x0, ttl 64, id 36768, offset 0, flags [DF], proto TCP (6), length 662) x.31.129.217.5672 > x.31.129.206.45604: Flags [P.], cksum 0x83a3 (correct), seq 959640600:959641210, ack 3516429040, win 243, options [nop,nop,TS val 3070303066 ecr 3070033633], length 610 E.....@.@.L..........(.$92....r............ ...Z..........].<.<.1.......N.&reply_d5cb71955a3a4a39b1e8f6539a72be4f&reply_d5cb71955a3a4a39b1e8f6539a72be4f.......+.<.............application/json.utf-8..............{"oslo.message": "{\"_msg_id\": \"ae4ea417e79c43af9d1cd2d603b32076\", \"failure\": null, \"_unique_id\": \"e357642aaef34d1fbaa4d240c405d572\", \"result\": {\"internal_access_path\": null, \"host\": \"x.31.129.164\", \"access_url\": \"https://api.secret.cloud:6080/vnc_auto.html?token=44b7d9be-2aab-4239-914c-9…", \"token\": \"44b7d9be-2aab-4239-914c-971d615fa9c0\", \"port\": \"5912\"}, \"ending\": true}", "oslo.version": "2.0"}. (3) :~# dpkg -l | grep amqp ii python-amqp 1.4.9-1 all Low-level AMQP client :~# dpkg -l | grep oslo.messaging ii python-oslo.messaging 5.10.0-0ubuntu2~cloud0 all oslo messaging library - Python 2.x :~# dpkg -l | grep nova ii nova-api-os-compute 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute - OpenStack Compute API frontend ii nova-cert 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute - certificate management ii nova-common 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-conductor 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute - conductor service ii nova-consoleauth 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute - Console Authenticator ii nova-novncproxy 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute - NoVNC proxy ii nova-scheduler 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute - virtual machine scheduler ii python-nova 2:14.1.0-0ubuntu1~cloud0 all OpenStack Compute Python libraries ii python-novaclient 2:6.0.0-0ubuntu1~cloud0 all client library for OpenStack Compute API - Python 2.7 :~# pip list | grep amqp amqp (1.4.9) :~# pip list | grep oslo oslo.cache (1.14.0) oslo.concurrency (3.14.0) oslo.config (3.17.0) oslo.context (2.9.0) oslo.db (4.13.3) oslo.i18n (3.9.0) oslo.log (3.16.0) oslo.messaging (5.10.0) oslo.middleware (3.19.0) oslo.policy (1.14.0) oslo.privsep (1.13.0) oslo.reports (1.14.0) oslo.rootwrap (5.1.0) oslo.serialization (2.13.0) oslo.service (1.16.0) oslo.utils (3.16.0) oslo.versionedobjects (1.17.0)

1 1

[cinder]db online_data_migrations error in rocky release
by Rambo 15 Apr '19

15 Apr '19

Hi,all When we configured backend_host (not host) for cinder-volume HA, then we execute the cli "cinder-manage db online_data_migrations", and we can get the following error: "Error attempting to run shared_targets_online_data_migration: MessagingTimeout: Timed out waiting for a reply to message ID".The problem can be reproduced by deploying cinder-volume with pacemaker.And I have set the backend_host = hostgroup, the "host" is not set. The reason of this I found that there will be an rpc call for all service.host. When the service.host is "hostgroup@ssd", because the "hostgroup" host is virtual, so theis is error. I have raise this as a bug. Can you tell me more about this? Thank you very much. Ref: https://github.com/openstack/cinder/blob/master/cinder/cmd/manage.py#L111 https://bugs.launchpad.net/cinder/+bug/1824509 Best Regards Rambo

1 0

[ops] Operators Informal Gathering at Summit, Monday night
by David Medberry 14 Apr '19

14 Apr '19

Hi all, Typically at large OpenStack events, the Operators try and assemble a bit more casually to blow off steam and have some 1:1 time. And as the Open Infrastructure Summit in Denver approaches (aka OpenStack Summit), we're planning another one. Monday night, April 29th, the early evening starts with the usual Marketplace. It runs until 7pm. Consequently, I'm proposing an "after" gathering at Wynkoop Brewery starting at 7:30pm until whenever. Wynkoop has a second floor with a number of pool tables and a casual environment. Many of the Operators met there last fall during the OpenStack PTG. As more operators will be at the Summit (first half of the week) we'll have this gathering on Monday instead of later in the week during the PTG. Many teams and companies have their own event on Monday evening but it looks to provide the best opportunity to get the operators together. This will be a "dutch treat" ie, pay your own bill event as no one is underwriting it and it is NOT an official Open Infra event. However, I'd appreciate a reply if you will be able to join the operators. (Wynkoop Brewing is on the north end and a couple blocks off of the 16th St Mall but the MallRide buses that circulate will get you most of the way there. It sits 1/2 way between 16th St and Coors Field. The pool room is upstairs. And although it's a brewery, think of it more as a brewpub as it has a full bar, not just beers. And of course has a pub-style food menu as well. More info here: https://wynkoop.com/ / Also, it may be the only brewery founded by any of the dozens of people running for 2020 United States president.)

1 0

[CI] nested virtualization support in OpenStack CI
by Guo, Ruijing 14 Apr '19

14 Apr '19

Hi, OpenStack CI runs on VM, which is not nested virtualization as: 2019-03-27 06:45:07.282 | flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl cpuid pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm pti however, I want to add new CI which depends on nested virtualization. which team can help me? Thanks, -Ruijing

6 19

how to define a flavor... numa topology and/or cpu pinning?
by Manuel Sopena Ballesteros 14 Apr '19

14 Apr '19

Hi, considering my hosts have numa architecture. what is the difference between "numa topology" and "cpu pinning"? would "cpu pinning" make any difference if "numa topology" is already in place? thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

2 1

[Vitrage] Find solution on integrate vitrage to current monitor
by hoanq13＠viettel.com.vn 14 Apr '19

14 Apr '19

Hi, I sent this mail for finding solution when integrate vitrage to my current monitor system. I my system we use Tick stack monitor: with telegraf is collector metric, influxdb for storing metric, and kapacitor for alarming. It been work for a long while, all our monitor data in influxdb. I'm wondering have any tool can read influxdb, create alarm so vitrage can get input alarm from it?. Or any ideal you can recommend me on integrate vitrage to my system? p/s: i was think about write datasource driver kapacitor can alarm vitrage, but it take time, and I'm not good at codding.

2 3

[neutron][hyperv] Neutron Hyper-V agent - unable to bind port
by Henry Bonath 14 Apr '19

14 Apr '19

Hello, I am relatively new to Openstack, and am not sure if support-type questions are welcome here, but if they are, any help would be greatly appreciated! I have a fully working system running Rocky that I built using Openstack-Ansible on Ubuntu 18.04. I am using it as a POC to test out for use in my datacenter, which has a large Hyper-V investment. I am using the ML2 Linuxbridge agent with my KVM hosts, with VLAN, VXLAN, and FLAT networking all working great. While attempting to add some Hyper-V nodes into the mix, all is working fine, I can provision new Instances from image, Cinder volumes mount via iSCSI, and they boot up successfully. The issue is that the Hyper-V virtual switch remains in a disconnected state, and does not tag a VLAN when it should. The port state also shows as "down" in the Horizon Web UI or from the Command line. On my neutron server containers, I have installed the "networking-hyperv" driver. My /etc/neutron/plugins/ml2/ml2_conf.ini file has the following: [ml2] extension_drivers = port_security,qos mechanism_drivers = linuxbridge,hyperv tenant_network_types = vxlan,flat,vlan type_drivers = flat,vlan,vxlan,local Neutron Server Container Logs: ( I think the key line is: Device fbb9010c-3326-4689-b46c-c3393e43f23b has no active binding in host None ) 2019-04-14 02:10:59.141 805 DEBUG neutron.db.db_base_plugin_common [req-c40d2349-2ade-4367-a017-181e6644c1fb 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] Allocated IP 172.31.60.62 (7559f5d9-bf1e-431a-b947-af8cc85bcf91/0c59baf1-3880-4b6c-8198-037923ec8cfb/fbb9010c-3326-4689-b46c-c3393e43f23b) _store_ip_allocation /openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/db/db_base_plugin_common.py:121 2019-04-14 02:10:59.151 805 DEBUG neutron.db.db_base_plugin_common [req-c40d2349-2ade-4367-a017-181e6644c1fb 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] Allocated IP 2001:470:3ab1:ff3c::11 (7559f5d9-bf1e-431a-b947-af8cc85bcf91/d6704a54-bdd2-4ced-a1c6-ea425e87f772/fbb9010c-3326-4689-b46c-c3393e43f23b) _store_ip_allocation /openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/db/db_base_plugin_common.py:121 2019-04-14 02:10:59.826 805 DEBUG neutron.db.provisioning_blocks [req-c40d2349-2ade-4367-a017-181e6644c1fb 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] Transition to ACTIVE for port object fbb9010c-3326-4689-b46c-c3393e43f23b will not be triggered until provisioned by entity DHCP. add_provisioning_component /openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/db/provisioning_blocks.py:73 2019-04-14 02:10:59.964 805 DEBUG neutron.api.rpc.handlers.resources_rpc [req-c40d2349-2ade-4367-a017-181e6644c1fb 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - - -] Pushing event updated for resources: {'Port': ['ID=fbb9010c-3326-4689-b46c-c3393e43f23b,revision_number=2']} push /openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/api/rpc/handlers/resources_rpc.py:241 2019-04-14 02:11:02.847 1024 INFO neutron.wsgi [req-f5b3d393-7550-477d-9dac-118149b09680 343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d - default default] 192.168.41.6,192.168.41.58 "PUT /v2.0/ports/fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200 len: 1169 time: 2.3884900 2019-04-14 02:11:03.366 1024 INFO neutron.notifiers.nova [-] Nova event response: {u'status': u'completed', u'tag': u'fbb9010c-3326-4689-b46c-c3393e43f23b', u'name': u'network-changed', u'server_uuid': u'4286e04d-84f7-4e1d-9ad6-d150debafca1', u'code': 200} 2019-04-14 02:11:03.438 788 INFO neutron.wsgi [req-e491113e-0eec-4688-bbb4-835fa2473c0f 343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d - default default] 192.168.41.6,192.168.41.58 "GET /v2.0/floatingips?fixed_ip_address=2001%3A470%3A3ab1%3Aff3c%3A%3A11&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200 len: 212 time: 0.0544460 2019-04-14 02:11:04.616 1024 INFO neutron.wsgi [req-c3b90556-cd97-40d8-90d5-ac7fbf19247b 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] 192.168.41.151,192.168.41.58 "GET /v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200 len: 212 time: 0.0501890 2019-04-14 02:11:21.842 1024 INFO neutron.wsgi [req-b7271e74-bffe-40fc-b7c5-9f50c2496626 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] 192.168.41.151,192.168.41.58 "GET /v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200 len: 212 time: 0.0771079 2019-04-14 02:11:45.530 790 DEBUG neutron.plugins.ml2.rpc [req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Device fbb9010c-3326-4689-b46c-c3393e43f23b details requested by agent hyperv_HOST-H with host None get_device_details /openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:79 2019-04-14 02:11:45.731 790 DEBUG neutron.plugins.ml2.db [req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] For port fbb9010c-3326-4689-b46c-c3393e43f23b, host HOST-H, got binding levels [<neutron.plugins.ml2.models.PortBindingLevel[object at 7f505617b910] {port_id=u'fbb9010c-3326-4689-b46c-c3393e43f23b', host=u'HOST-H', level=0, driver=u'hyperv', segment_id=u'598c754b-1b2a-4865-9211-ef3a1e5ed95c'}>] get_binding_levels /openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/plugins/ml2/db.py:77 2019-04-14 02:11:45.753 790 DEBUG neutron.plugins.ml2.rpc [req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Device fbb9010c-3326-4689-b46c-c3393e43f23b has no active binding in host None _get_device_details /openstack/venvs/neutron-18.1.4/lib/python2.7/site-packages/neutron/plugins/ml2/rpc.py:133 2019-04-14 02:11:49.538 1024 INFO neutron.wsgi [req-4213915d-3fee-40ff-8921-439c9ada3a30 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] 192.168.41.151,192.168.41.58 "GET /v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200 len: 212 time: 0.0534980 2019-04-14 02:12:07.359 788 INFO neutron.wsgi [req-6d6e94e6-9100-4923-894a-341a9b4be439 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] 192.168.41.151,192.168.41.58 "GET /v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200 len: 212 time: 0.0527611 2019-04-14 02:12:29.106 789 INFO neutron.wsgi [req-507d6cf9-a93e-4988-948c-e409dc226de7 202a012dda274d0a8e974e22690e340f fde3db651e3a424a95a34bef449949a3 - default default] 192.168.41.151,192.168.41.58 "GET /v2.0/floatingips?tenant_id=fde3db651e3a424a95a34bef449949a3&port_id=fbb9010c-3326-4689-b46c-c3393e43f23b HTTP/1.1" status: 200 len: 212 time: 0.0640750 Neutron Hyper-V Agent Log: ( Key line here is: No port fbb9010c-3326-4689-b46c-c3393e43f23b defined on agent ) 2019-04-13 22:11:02.830 4220 DEBUG networking_hyperv.neutron.agent.layer2 [req-f5b3d393-7550-477d-9dac-118149b09680 343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d - - -] port_update received: fbb9010c-3326-4689-b46c-c3393e43f23b port_update C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:436 2019-04-13 22:11:02.846 4220 DEBUG networking_hyperv.neutron.agent.layer2 [req-f5b3d393-7550-477d-9dac-118149b09680 343681e3a838455796d46e4449625438 1868e5b19c6443c7a0ec010ece16447d - - -] No port fbb9010c-3326-4689-b46c-c3393e43f23b defined on agent. port_update C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:449 2019-04-13 22:11:44.890 4220 INFO networking_hyperv.neutron.agent.layer2 [-] Hyper-V VM vNIC added: fbb9010c-3326-4689-b46c-c3393e43f23b 2019-04-13 22:11:45.530 4220 DEBUG networking_hyperv.neutron.agent.layer2 [req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Agent loop has new devices! _work C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:427 2019-04-13 22:11:45.765 4220 INFO networking_hyperv.neutron.agent.layer2 [req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Adding port fbb9010c-3326-4689-b46c-c3393e43f23b 2019-04-13 22:11:45.765 4220 DEBUG networking_hyperv.neutron.agent.layer2 [req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Missing port_id from device details: fbb9010c-3326-4689-b46c-c3393e43f23b. Details: {'device': 'fbb9010c-3326-4689-b46c-c3393e43f23b', 'no_active_binding': True} _treat_devices_added C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:374 2019-04-13 22:11:45.765 4220 DEBUG networking_hyperv.neutron.agent.layer2 [req-feb90349-b6da-4c5f-9d6b-027bc4b6e36b - - - - -] Remove the port from added ports set, so it doesn't get reprocessed. _treat_devices_added C:\Program Files\Cloudbase Solutions\OpenStack\Nova\Python\lib\site-packages\networking_hyperv\neutron\agent\layer2.py:376 If I happen to "catch" the VM in the Hyper-V console while it's being provisioned, I can attach the vNIC to the Hyper-V Switch, and check the box and tag the VLAN and the system will get an IP from the DHCP Agent, Pull its hostname and ssh key from the Metadata Agent, and everything else - although Openstack will still have the port status as "Down" There's not a lot of info out there on specific nuances of Nova with Hyper-V, If I need to look into the Open vSwitch Agent, I'm not opposed to going that direction either. I also realize that I may need to reach out to Cloudbase directly for better support. Thanks for your consideration and support! -Henry

1 0

[openstack-ansible] Documentation of host OS major upgrade
by Gilles Mocellin 13 Apr '19

13 Apr '19

Hello, I'm actually using OpenStack-Ansible to deploy a little public cloud. For now it runs on Queens / Ubuntu 16.04. I've read that Rocky will be the only release supported on both Ubuntu 16.04 and Ubuntu 18.04 with OpenStack-Ansible. Stein being out soon (with OpenStack-Ansible), the question of Host OS upgrade from Ubuntu 16.04 to ubuntu 18.04 is a big thing of this year. I've not found any documentation about that upgrade path (Rocky->Stein, host OS). I had some answers on IRC that OpenStack Ansible does not support a mixed environnement (adding compute nodes on Ubuntu 18.04 while the rest is on Ubuntu 16.04 for example). Did I miss something in the actual doc or in some blogs ? I'm sure some users already faced this with transition fro Ubuntu 14.04 to Ubuntu 16.04. There's certainly some material to start some documentation and add it to https://docs.openstack.org/openstack-ansible/stein/admin/upgrades/ major-upgrades.html. I know that there's less contributors now, I'll see if I can help. Thanks.

3 3

[release][stable][trove] Please add Lingxian Kong to trove-stable-maint group
by Lingxian Kong 13 Apr '19

13 Apr '19

Hi Stable Maintenance Core team, I'm current Trove PTL, could you please add myself to trove-stable-maint so that I could merge those patches[1][2][3] for stable/stein? [1] https://review.openstack.org/#/c/645647/ [2] https://review.openstack.org/#/c/645646/ [3] https://review.openstack.org/#/c/645648/ --- Cheers, Lingxian Kong Catalyst Cloud

5 19

[dev][stable][release][manila] Should we revert these stable branch backports?
by Tom Barron 13 Apr '19

13 Apr '19

In manila we recently merged backports of a change [1] that aims to fix up faulty configuration option deprecations in the Dell-EMC VMAX driver. The question at hand is whether (a) we should revert these backports on the grounds that the deprecations were faulty and therefore are only effective from Stein forwards, or whether (b) the deprecations actually worked and took effect back when Ocata was the development branch but had faults that should be corrected all the way back to Pike before it goes EM. I think (b) is the correct answer but let's check. On Jan 10 2017 a review [2] merged that deprecated generic Dell-EMC driver options in favor of model-specific options [2]. There were two models at the time, Unity and VNX. This change was in itself unproblematic. On Jan 24 2017 a review [3] merged that introduced a third Dell-EMC model, VMAX. This new code introduced VMAX specific options, consistent with the deprecation of the generic Dell-EMC options. However it had two problems which review [1] corrects. When it defined the new VMAX-specific options it failed to indicate the corresponding old generic options via 'deprecated_name' [4]. Worse, the code that consumed the options actually looked for the old generic 'emc_interface_ports' option instead of the new 'vmax_ethernet_ports' option. The only way to set a value for this option was to use its deprecated form. The change that we backported fixes both of these problems. I think it is a valid stable backport. If people set this "ports" option using the deprecated option it will still work. The deprecated option has not been removed yet and will never be removed from any of the stable branches. If they tried to set it via the proper option then they would have had a functional problem, a bug, which this change now fixes. If on the other hand we say we cannot backport this then until stable/stein there will be no way for VMAX users of earlier stable branches to set this option except by magic -- by using an old deprecated form of the option that without the backported fix is not even visible in the customer-facing configuration for VMAX. All this said, I could well be missing something so I welcome analysis by stable/core folks. The backports in question have not yet been released so it would not be a problem to revert them. Thanks! -- Tom Barron [1] https://review.openstack.org/#/c/608725/ [2] https://review.openstack.org/#/c/415079/ [3] https://review.openstack.org/#/c/404859/ [4] If this was the only issue then arguably it wasn't an error since the VMAX driver never operated with the old options.

3 9

[Zun] Heat and Horizon Support
by Navdeep Uniyal 13 Apr '19

13 Apr '19

Dear All, I would like to integrate my Zun deployment (OS Rocky) with Heat and Horizon. For horizon, I used the instructions given in https://docs.openstack.org/zun-ui/rocky/install/index.html However, while adding the files to /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled Using : cp zun_ui/enabled/* /usr/lib/python2.7/dist-packages/openstack_dashboard/local/enabled My openstack UI is breaking down : [cid:image001.jpg@01D4EFB9.89E6F5B0] Please advise. Kind Regards, Navdeep

3 4

[dev][keystone] Keystone Team Update - Week of 8 April 2019
by Colleen Murphy 12 Apr '19

12 Apr '19

# Keystone Team Update - Week of 8 April 2019 ## News ### Stein Release Keystone has been released for Stein! Congrats on a great release! ### Predictable IDs We're starting to move forward[1][2][3][4] with Adam's predictable IDs initiative[5], including discussing[6] whether and how to migrate deployments to using hashed IDs so that they can become multi-site ready. [1] https://review.openstack.org/605169 [2] https://review.openstack.org/650615 [3] https://review.openstack.org/605235 [4] https://review.openstack.org/651655 [5] https://review.openstack.org/612099 [6] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ### Admin endpoint Jens is working on getting us on track to remove the admin endpoint from deployments[7][8], since keystone is the only service that uses it and it's no longer needed in a V3-only world. There are a few hardcoded defaults that make the switchover less than straightforward that we're working out[9]. [7] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.… [8] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.… [9] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh Train specs have begun! Please review the open spec proposals so we can discuss them at the PTG. ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 31 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 24 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 2 new bugs and closed 4. Bugs opened (2) Bug #1823847 (keystone:Undecided) opened by Shivakumar M https://bugs.launchpad.net/keystone/+bug/1823847 Bug #1824239 (keystone:Undecided) opened by Adam Young https://bugs.launchpad.net/keystone/+bug/1824239 Bugs closed (1) Bug #1823847 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1823847 Bugs fixed (3) Bug #1779889 (keystone:Medium) fixed by Kristi Nikolla https://bugs.launchpad.net/keystone/+bug/1779889 Bug #1641639 (keystone:Wishlist) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1641639 Bug #1794527 (keystone:Wishlist) fixed by Adam Young https://bugs.launchpad.net/keystone/+bug/1794527 ## Milestone Outlook https://releases.openstack.org/train/schedule.html The Train cycle will open next week. We'll need to decide on deadlines for the cycle soon. ## Shout-outs Thanks everyone for making this a great release! Looking forward to seeing what we can accomplish next cycle :) ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

Upgrading the lists.(openstack|airshipit|starlingx|zuul-ci).org server Friday April 12
by Clark Boylan 12 Apr '19

12 Apr '19

It is that time of the Ubuntu LTS cycle again and we need to upgrade our mailman mailing list server. We'd like to do that this Friday, April 12. We expect the upgrade to begin at about 17:00UTC and result in a 30-45 minute outage. The reason for the extended outage is that we will be upgrading the server in place to preserve its mail reputation. Thankfully email is a persistent system and your clients should queue up email sent until the server is back up again and accepting smtp connections. This means the outage shouldn't be very noticeable. Finally, for list admins, there are new DMARC moderation action settings. We ask that you don't change these settings and instead work with us if you need to address DMARC problems. Our current preference is that we pass email through unmodified so that the signatures still validate. Thank you all for your patience and feel free to ask us questions, Clark

1 1

[placement] update 19-14
by Chris Dent 12 Apr '19

12 Apr '19

HTML: https://anticdent.org/placement-update-19-14.html Placement update 19-14 is here. There will be no 15, 16 or 17 due to various bits of travel. There will be some PTG-related summaries. # Most Important The [Virtual Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/… is in full swing and making some good progress towards making sure that we only hit the hard stuff at the in-person PTG. Apologies if it has been a bit overwhelming. The hope is that by paying the price of a bit more whelm now we will have less whelm at the PTG. If you have questions, please ask. Links to all the threads are in the PTG etherpads: * <https://etherpad.openstack.org/p/placement-ptg-train> * <https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement> There's also a [retrospective etherpad](https://etherpad.openstack.org/p/placement-ptg-train-retrospectiv…. # What's Changed * The [0.12.0 release of os-traits](https://review.openstack.org/652079) is pending. It switches that package to using the independent release policy. os-resource-classes will get the same treatment when we next need to release it. # Specs/Features There are four specs in flight in the placement repo and one pending to be ported over from nova: * <https://review.openstack.org/649992> support any trait in allocation candidates * <https://review.openstack.org/649368> support mixing required traits with any traits * <https://review.openstack.org/650476> Allocation Candidates: Subtree Affinity. There's discussion related to this happening in [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/00… as part of the pre-PTG. * <https://review.openstack.org/651113> Support filtering by multiple trees. * <https://review.openstack.org/597601> Request group mapping spec is still in Nova, but discussion is happening in [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/00… generating a plan for how to proceed. There are also several nova-specs that were visited in the [nova spec review day](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/0044… earlier this week. Some are listed below. # Bugs * StoryBoard stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement): 15. Up by 9. 0 are [untagged](https://storyboard.openstack.org/#!/worklist/580). Part of the reason for the increase is because Matt did the fine work of moving osc-placement bugs over from launchpad. * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 13. No change. * [In progress placement bugs](https://goo.gl/vzGGDQ) on launchpad: 4. -1. Those that remain are placement-related, but in nova. # osc-placement osc-placement is currently behind by 13^w11 microversions. -1 since last week. Support for 1.19 has just merged. Oh wait, no, -3. 1.21 has just merged. There was nothing to do for 1.20. Pending changes: * <https://review.openstack.org/#/c/640898/> Add 'resource provider inventory update' command (that helps with aggregate allocation ratios). * <https://review.openstack.org/#/c/651783/> Add support for 1.22 microversion * <https://review.openstack.org/586056> Provide a useful message in the case of 500-error * <https://review.openstack.org/650257> Remove unused cruft from doc and releasenotes config * <https://review.openstack.org/652100> Improve aggregate version check error messages with min_version * <https://review.openstack.org/651939> Use PlacementFixture in functional tests. Result of discussion in [email](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/00… in the pre-PTG # Main Themes More work remains in the pre-PTG discussions to try to drive towards some themes. The specs above capture some of it, but it appears like a lot of the work will be a) supporting other projects doing things with Placement, b) fixing bugs they discover. # Other Placement Mostly specs in progress (listed above) for now. * <https://review.openstack.org/#/c/645255/> This is a start at unit tests for the PlacementFixture. It is proving a bit "fun" to get right, as there are many layers involved. Making sure seemingly unrelated changes in placement don't break the nova gate is important. Besides these unit tests, there's discussion on the PTG etherpad of running the nova functional tests, or a subset thereof, in placement's check run. On the one hand this is a pain and messy, but on the other consider what we're enabling: Functional tests that use the real functionality of an external service (real data, real web requests), not stubs or fakes. There's a pre-PTG [thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/0… for this. * <https://review.openstack.org/641404> Use ``code`` role in api-ref titles * <https://review.openstack.org/#/q/topic:refactor-classmethod-diaf> A sequence of refactorings, based off discussion in yet another pre-PTG [thread](http://lists.openstack.org/pipermail/openstack-discuss/2019-April/0…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. * <https://review.openstack.org/552924> Nova: Spec: Proposes NUMA topology with RPs * <https://review.openstack.org/622893> Nova: Spec: Virtual persistent memory libvirt driver implementation * <https://review.openstack.org/641899> Nova: Check compute_node existence in when nova-compute reports info to placement * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1790204> Workaround doubling allocations on resize * <https://review.openstack.org/555081> Nova: Spec: Standardize CPU resource tracking * <https://review.openstack.org/645316> Nova: Pre-filter hosts based on multiattach volume support * <https://review.openstack.org/606199> Ironic: A fresh way of looking at step retrieval * <https://review.openstack.org/647396> Nova: Add flavor to requested_resources in RequestSpec * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/640080> Nova: Use aggregate_add_host in nova-manage * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Nova: count quota usage from placement * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/624335> puppet-tripleo: Initial extraction of the Placement service from Nova * <https://review.openstack.org/648665> Nova: Spec for a new nova virt driver to manage an RSD * <https://review.openstack.org/#/c/642067/> Helm: Allow more generic overrides for nova placement-api * <https://review.openstack.org/609960> Support filtering of allocation_candidates by forbidden aggregates * <https://review.openstack.org/625284> Cyborg: Initial readme for nova pilot * <https://review.openstack.org/629142> Tempest: Add QoS policies and minimum bandwidth rule client * <https://review.openstack.org/641994> Nova-spec: Re-approve AMD SEV support for Train * <https://review.openstack.org/648687> Nova-spec: Add PENDING vm state * <https://review.openstack.org/#/q/topic:bug/1777591> Nova: use in_tree in RequestGroup * <https://review.openstack.org/650856> kolla-ansible: Remove placement migration code * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.openstack.org/651024> nova-spec: RMD Plugin: Energy Efficiency using CPU Core P-State control * <https://review.openstack.org/651455> puppet: Debian: Add support for placement-api over uwsgi * <https://review.openstack.org/650963> nova-spec: Proposes NUMA affinity for vGPUs. This describes a legacy way of doing things because affinity in placement may be a ways off. But it also [may not be](https://review.openstack.org/650476). * <https://review.openstack.org/649882> nova-spec: Separate the vCPUs into different pools based on priority * <https://review.openstack.org/#/q/topic:heal_allocations_dry_run> Nova: heal allocations, --dry-run * <https://review.openstack.org/642527> Neutron: Fullstack test for placement sync # End There's a lot going on. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

"Open Infrastructure & Cloud Native Days Korea 2019" is looking for Sponsors and Speakers
by Ian Y. Choi 12 Apr '19

12 Apr '19

Dear OpenStack Community Members, This year, I would like to announce that there will be "Open Infrastructure & Cloud Native Days Korea 2019" in Korea , with tight collaboration with Kubernetes & Ceph Korea User Groups (July 18th - 19th)! This is the sixth event succeeding from the first OpenStack Days Korea event in 2014. Each of five previous events had a huge success and attracted lots of interest among IT expert, engineers, developers and Executives. The event will be held on three near-buildings at Eulji-ro area in Seoul. There will be various keynotes, presentations, hands-on-labs,and attractive keynotes on timely and in-depth technologies and solutions. In order to successfully execute this event, we will need your help on both sponsoring and your participation on the event. https://openinfradays.kr/index_en.html In the above event webpage, you will find link for both “Sponsorship” and “Call for Speakers”. Please kindly review and consider sponsorship, and get back to us. If you have any question, you can contact one of organizers in OpenInfra Days Korea & Cloud Native Days Korea 2019 event stated at the end of this email. In addition, if you are interested in speaking at the event, please fill the form at “Call for Speakers” link (or please directly visit to Google Form : https://goo.gl/forms/ovsT0zQVauLaDlHg2 ) Thank you very much in advance, and we look forward to working with you. Best Regards, OpenStack Korea User Group – Ian Y. Choi (ianyrchoi at gmail.com) Kubernetes Korea User Group Leader: Seungkyu Ahn (seungkyua at gmail.com) Ceph Korea User Group Leader: Seungjin Han (yongiman at gmail.com) Program Chair – Jaesuk Ahn (bluejay.ahn at gmail.com) Event Organizing Chair – Jungwon Ku (jwon.ku at gmail.com)

1 0

[osprofiler] Distributed tracing in OpenStack
by Ilya Shakhat 12 Apr '19

12 Apr '19

Hi, Distributed tracing is one of must-have features when one wants to track the full path of request going through different services and APIs. This makes it similar to shared request-id, but with nice visualization at the end [1]. In OpenStack the tracing can be achieved via osprofiler library. The library was introduced 5 years ago, and back then there was no standard approach on how to do tracing and that's why it stays aside from what has become a mainstream. Yet there is no single standard, but the major players are OpenTracing and OpenCensus communities. OpenTracing is represented by Uber's Jaeger which is the default tracer from k8s world. Issues and limitations to be fixed: 1. Compatibility. While osprofiler library supports many different storage drivers, it has only one way of transferring trace context over the wire. Ideally the library should be compatible with other third-party tracers and allow traces to start in front of OpenStack APIs (e.g. in user apps) and continue after (e.g. in storage systems, or network management tools). [2] 2. Operation mode. With osprofiler tracing is initiated by user request, while in industrial solutions the tracing can be managed centrally via dynamic sampling policies. 3. In-process trace propagation. Depending on execution model (threaded, async) the ways of storing current trace context differ. OSProfiler supports thread-local model, which recently got broken with new async implementation in openstacksdk [3]. With OpenTracing it is possible to select the appropriate model alongside with tracer configuration. What's the plan: Switching to OpenTracing could be a good option to gain compatibility with 3rd-party solutions. The actual change should go to osprofiler library, but indirectly affects all OpenStack projects (should it be a global team goal then?). I'm going to make a PoC of proposed change, so reviews would be highly appreciated. Comments, suggestions? Thanks, Ilya [1] e.g. http://logs.openstack.org/15/650915/4/check/tempest-smoke-py3-osprofiler-re… [2] https://bugs.launchpad.net/osprofiler/+bug/1798565 [3] https://bugs.launchpad.net/osprofiler/+bug/1818493

4 4

[placement][nova][ptg] Protecting driver-provided traits
by Chris Dent 12 Apr '19

12 Apr '19

>From the etherpad [0]: * We might want to tighten up what the RP traits API allows as per https://pasteboard.co/I3iqqNm.jpg * although maybe this is better covered in a nova session? * If the mechanism is changing how nova-compute reports and manipulates traits, then yeah, nova. But if for some reason there is a need to change the actual API [1], placement; but I would hope that all avenues not involving changing the API were first disposed as either not possible, or really really terrible. This came up as part of the work on compute capabilities as traits [2] and questions about who owns what traits and how to manage them so that unexpected trait clobbering or trait addition happens. This is (hopefully) mostly a thing on the nova-compute side of the equation (when managing inventory), so hopefully someone with more insight into that situation can drive this thread. What needs to happen here? [0] https://etherpad.openstack.org/p/placement-ptg-train [1] There are degrees of change in the API. Adding a query parameter is much less of a big deal than adding or changing an attribute in a request or response body. Adding another method to a URI, while a big deal in some cases, is much less of a big deal than adding an entirely new URI. [2] https://review.openstack.org/#/c/538498/k -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 7

[all][tc] Repository renames during OpenDev migration
by Jim Rollenhagen 12 Apr '19

12 Apr '19

Hi all, During the migration to OpenDev, we plan to change the way we organize some of our repositories. Before you ask, yes, there will be redirects. The TC has made some decisions about this[0]; this email is a re-iteration of the plan and a call for any last minute feedback. Here's how a repository's new namespace will be decided, as it stands today: - is the repo listed in projects.yaml[2]? If so, "openstack". - is the repo listed in legacy.yaml[3]? If so, "openstack". - is the repo listed in foundation-board-repos.yaml[4]? If so, "openstack". - is the repo listed in sigs-repos.yaml[5]? If so, "openstack". - is the repo listed in technical-committee-repos.yaml[6]? If so, "openstack". - is the repo listed in user-committee-repos.yaml[7]? If so, "openstack". - has the repo owner requested a new name(space) in the transition ethercalc sheet[1]? If so, use that. - anything else? A few of us from the TC will manually review the list to make sure we didn't miss anything that is an official OpenStack repo. Anything left will be moved to another namespace[8] unless/until the owner requests it to be moved elsewhere. [0] https://governance.openstack.org/tc/resolutions/20190322-namespace-unoffici… [1] https://ethercalc.openstack.org/opendev-transition [2] https://opendev.org/openstack/governance/src/branch/master/reference/projec… [3] https://opendev.org/openstack/governance/src/branch/master/reference/legacy… [4] https://opendev.org/openstack/governance/src/branch/master/reference/founda… [5] https://opendev.org/openstack/governance/src/branch/master/reference/sigs-r… [6] https://opendev.org/openstack/governance/src/branch/master/reference/techni… [7] https://opendev.org/openstack/governance/src/branch/master/reference/user-c… [8] I'm not even going to name it here, lest this thread devolves into a discussion about this name and nothing else. // jim

5 8

[Watcher] Proposing chenker and Dantalion for core
by li.canwei2＠zte.com.cn 12 Apr '19

12 Apr '19

Hi, Now Watcher need more active core reviewers, I'd like to propose adding chenker and Dantalion to core team. They all did a great contribution during the last six months [1]. [1]: https://www.stackalytics.com/report/contribution/watcher-group/90 Thanks! Canwei Li

3 2

[tc][telemetry] Asking core privileges on Telemetry projects
by Trinh Nguyen 12 Apr '19

12 Apr '19

Dear TC, As I am the new PTL for Telemetry in Train [1] and the current cores seem inactive, I would like to ask the TC team to grant myself < dangtrinhnt(a)gmail.com> and Lingxian Kong <anlin.kong(a)gmail.com> to the core team of these Telemetry managed projects: + ceilometer + aodh + panko Next step for me is to re-organize core members and meetings. Many thanks, [1] https://review.openstack.org/#/c/645122/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

5 9

Unshelve in nova, cinder initialize_connection with user context
by Jordan Ansell 12 Apr '19

12 Apr '19

Hello, I have encountered what appears to be an edge-case instance shelving situation. I have to allow access to an internal API call to enable an "unprivileged" user to perform an instance operation. Specifically, I have a user with a "restricted permission" role in a project, who should only be able to start/stop/shelve/unshelve an existing instance. With sensible roles/actions in the nova policy, they are able to perform all actions, except /un/shelving. This should be controlled by a nova policy, however the user is unable to unshelve without permission to access the /cinder/ API call "initialize_connection() <https://developer.openstack.org/api-ref/block-storage/v3/?expanded=initiali…>". Without granting permission to the user, cinder rejects nova's request with an HTTP 403 status message. Outcomes of this situation are, curious and potentially unwanted. Curious being the user is able to /shelve/. Which leads to a point of no return for the user. But of particular concern is this API call exposes the backend storage driver's connection info to users. The RBD driver, as we use, does not even require a populated "connector" object before it replies. I was looking for advice/opinions on this issue, and hope someone here can help or direct me to the right place. My thoughts were that perhaps this is a bug or there's a configuration issue with our nova/cinder (note, i'm using mitaka, so maybe it's fixed upstream!). I am unable to check whether this is just a bug in nova, due to my lack of experience. But my rationale is nova is using the /user//'s/ context instead of an internal nova /admin/-like context to call the cinder API. As for configuration, I've been unable to pull up anything that seems relevant to this issue looking through /etc/{nova,cinder}/{nova,cinder}.conf, but maybe there's an option we've enabled that's led to this behavior. I'm happy to answer questions if anything is unclear. Sorry for verbosity, vagueness or inaccuracies -- I'm very new to Openstack, having started at zero a month ago and am using this task as a way to learn more. Any help is much appreciated :) Jordan

4 5

[placement][ptg] We like the perfload job, maybe we should rally?
by Chris Dent 12 Apr '19

12 Apr '19

>From the etherpad [1] * Or at least measure more things? Perfload has proven a useful (non-voting) test job for discovering when things are not behaving well under high writes and for having a rough understanding the performance of GET /allocation_candidates In a world of copious time we'd have more of this kind of measurement. Should we investigate Rally? It used to be the tool of choice for this kind of thing once upon a time. Is it still that time? Or should we continue using more focused and smaller setups, like perfload? If so, what should they be? Or is this something to worry about some other time? [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

5 5

[placement][ptg] Placement Over The Parapet
by Chris Dent 12 Apr '19

12 Apr '19

>From the etherpad [1]: * What's going on in the rest of the world: * where placement can help * that can help placement It's a whole big world out there, people doing all sorts of things that maybe look a bit like what placement does. What can we learn from them? What can they learn from us? In what ways can we expand placement world dominance and improve its ecosystem diversity? We are often so busy in the depths of OpenStack that it is hard to remain aware of what is out there. What is? For example, would there be any purpose in experimenting with plugging placement into the pluggable scheduling concept in k8s? Is that totally crazy or intriguing? I don't know because it's hard to make the time, but it would be valuable to know. [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

5 5

[all] New Zuul job to replicate a project's git repository to a remote git server
by David Moreau Simard 12 Apr '19

12 Apr '19

Hi, It is now possible for projects to replicate their git repository to a custom location by inheriting from the 'upload-git-mirror' job provided by Zuul. This job wraps around the 'upload-git-mirror' Ansible role that is part of the zuul-jobs library [1]. In order to use this job, you must supply a secret in the following format: === - secret: name: <name of your secret> data: user: <ssh user of the remote git server> host: <address of the remote git server> host_key: <ssh host key of the remote git server> ssh_key: <private key to authenticate with the remote git server> === The 'host_key' parameter can be retrieved from your known_hosts file or with a command like 'ssh-keyscan -H <host>' or 'ssh-keyscan -t rsa <host>'. For example, the 'host_key' when pushing to GitHub would be, on a single line: github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ== The 'ssh_key' parameter should be encrypted before being committed to the git repository. Zuul provides a tool for easily encrypting files such as SSH private keys and you can find more information about it in the documentation [2]. For example, encrypting a key for the "openstack/ara" project would look like this: === zuul/tools/encrypt_secret.py --infile /home/dmsimard/.ssh/ara_git_key --tenant openstack https://zuul.openstack.org openstack/ara === You would then use the secret in a job inheriting from 'upload-git-mirror' as such: === - job: name: <project>-upload-git-mirror parent: upload-git-mirror description: Mirrors openstack/<project> to neworg/<project> vars: git_mirror_repository: neworg/<project> secrets: - name: git_mirror_credentials secret: <name of your secret> pass-to-parent: true === Finally, the job must be set to run in your project's 'post' pipeline which is triggered every time a new commit is merged to the repository: === - project: check: jobs: # [...] gate: jobs: # [...] post: jobs: - <project>-upload-git-mirror === Note that the replication would only begin *after* the change has merged, meaning that merging the addition of the post job would not trigger the post job itself immediately. The post job will only trigger the next time that a commit is merged. [1]: https://zuul-ci.org/docs/zuul-jobs/general-roles.html#role-upload-git-mirror [2]: https://zuul-ci.org/docs/zuul/user/encryption.html David Moreau Simard dmsimard = [irc, github, twitter]

1 0

[octavia] Proposal to change the Octavia IRC meeting time.
by Michael Johnson 11 Apr '19

11 Apr '19

As the composition of the Octavia team has changed over time, it was proposed at today's meeting that we may want to change our weekly IRC meeting time to accommodate more participants from around the world. Seven time slots were proposed during the meeting and I have created a doodle poll to help us find a time that works for most of the team. Please note, the intent is to pick a new UTC time. Doodle attempts to adapt the times to your local timezone. The proposed times are Tuesday-Friday at 15:00 or 16:00 UTC. We have also included the current meeting time of 20:00 UTC on Wednesday. Please vote your preferences at the following Doodle poll: https://doodle.com/poll/9sxbzfhwirqiyqe8 We will discuss the results at next week's regularly scheduled IRC meeting, Wednesday at 20:00 UTC. Please reply to this e-mail or to me directly if you have trouble with the poll or would like to propose additional time slots. Michael

1 1

[placement][ptg] code refactoring constraints and goals
by Chris Dent 11 Apr '19

11 Apr '19

>From the etherpad [1] * We got a lot of value out of the ovo-ectomy and de-list. We're now at a stage where there is plenty more that could be done, but the choices are more subject to personal preference. * How (and should) we further split and shrink objects/resource_provider.py We got a lot of value out of the big refactoring the removed OVO and split objects/resource_provider.py into smaller files. It's also a stated goal that we should continue refactoring and continuously revisit existing code. However, we started to stumble because we had some disagreements on how to proceed. We should resolve those disagreements so we can proceed (he said, obviously). Questions that have come up (plus other ones I can think off the top of my head): * Is it worth reordering methods to some kind of arbitrary ordering? * If a method or module is "long" (by some definition) does that make it bad? * Where is the balance between backport hurting churn and keeping the mix fresh? * Should there be a more cleanly defined boundary between the methods that marshal data (the top-level methods in objects/*.py) and those that talk to the persistence layer (also in objects/*.py)? * Do we need to define (better) or document the layers/boundaries in the system? * How can we encourage a similar refactor/revisit-often attitude to the docs? There are plenty of other refactoring related thoughts too. Have at. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

4 11

[glance] Listing all images with a set of custom properties
by Nadathur, Sundar 11 Apr '19

11 Apr '19

I am looking for a way to programmatically get all images that have been associated with a set of custom properties. Ideally, I should be able to say 'give me all images that have key1=value1, key2=value2, etc. Failing that, at least get all images that have the named keys key1, key2, etc. irrespective of their values, so I can filter for the values myself. I was looking at [1], specifically [2], and came up short. Any recommendations? [1] https://github.com/openstack/python-glanceclient/tree/master/glanceclient/v2 [2] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v… Regards, Sundar

2 2

[PowerVMStackers][Winstackers][uc][tc] Encourage to transform from project to SIG
by Rico Lin 11 Apr '19

11 Apr '19

Dear PowerVMStackers and Winstackers members (This idea is from Thierry, so I'm just helping to trigger discussion here.) We now have most of Working Groups migrate to SIGs, so it's governance under both TCs and UCs. And to further look through, there are some projects are potential SIG meterial. PowerVMStackers and Winstackers are two identical targets. They all required cross-project works to achieve their mission and kind of *special interest* (One for PowerVM, and one for Windows support across OpenStack). There are two questions I would hope team members from both teams can help to answer. 1. Is the mission for your project completed? 2. Is the team still active? 3. Any concerns or objections on moving from project to SIG? If we agree to change from project to SIG, I expect most of the tools will stay the way it is. The only thing for the first step should just change your project definition from project to SIG (like from PowerVMStackers to PowerVM SIG). So it will not cause the team any effort for sure. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

10 22

Proposal to move cinder backup tests out of the integrated gate
by Matt Riedemann 11 Apr '19

11 Apr '19

I wanted to send this separate from the latest gate status update [1] since it's primarily about latent cinder bugs causing failures in the gate for which no one is really investigating. Running down our tracked gate bugs [2] there are several related to cinder-backup testing: * http://status.openstack.org/elastic-recheck/#1483434 * http://status.openstack.org/elastic-recheck/#1745168 * http://status.openstack.org/elastic-recheck/#1739482 * http://status.openstack.org/elastic-recheck/#1635643 All of those bugs were reported a long time ago. I've done some investigation into them (at least at the time of reporting) and some are simply due to cinder-api using synchronous RPC calls to cinder-volume (or cinder-backup) and that doesn't scale. This bug isn't a backup issue, but it's definitely related to using RPC call rather than cast: http://status.openstack.org/elastic-recheck/#1763712 Regarding the backup tests specifically, I don't see a reason why they need to be run in the integrated gate jobs, e.g. tempest-full(-py3). They don't involve other services, so in my opinion we should move the backup tests to a separate job which only runs on cinder changes to alleviate these latent bugs failing jobs for unrelated changes and resetting the entire gate. I would need someone from the cinder team that is more involved in knowing what their job setup looks like to identify a candidate job for these tests if this is something everyone can agree on doing. [1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000867… [2] http://status.openstack.org/elastic-recheck/ -- Thanks, Matt

6 12

[placement][ptg] Gate health management
by Chris Dent 11 Apr '19

11 Apr '19

>From the etherpad [1]: * We have to run grenade and tempest. They are both very very slow and very unreliable (compared to the other tests). That's a pain. How do we help fix it? * Profile where time is spent setting up devstack? * Figure out where the slowest tests are which aren't marked slow: http://status.openstack.org/elastic-recheck/#1783405 * Figure out which (non-interop) tests in tempest could be split out to per-project repos or tempest plugins, i.e. if there are compute API tests which don't rely on other services or a hypervisor, and are just API/DB, they could be dealt with in nova functional tests instead. * Similarly: http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000868… The main thing to add here: We can come up with strategies on how to fix it, but how can we assure that there is time/energy/people to do that work? [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

5 5

[cinder][qa] Skipped the unstable test_volume_backup_create_get_detailed_list_restore_delete
by Ghanshyam Mann 11 Apr '19

11 Apr '19

Hello Cinder team, Test test_volume_backup_create_get_detailed_list_restore_delete is failing very frequently now a days. 19 fails in 24 hrs / 137 fails in 10 days [1] I have skipped this test temproarly[2]. mriedem has pointed out the failure on review and cinder channel also, please refer that for more details. Feel free to propose to unskip this test once the problem is fixed. [1] http://status.openstack.org/elastic-recheck/#1483434 [2] https://review.openstack.org/#/c/651660/ -gmann

1 0

[horizon] Cinder API version in Horizon
by Massimo Sgaravatto 11 Apr '19

11 Apr '19

Hi If Horizon uses Cinder API v3 by default since Queens ([1])], why does the installation guide for Horizon [2] suggest to set in local_settings the v2 api for volume ? OPENSTACK_API_VERSIONS = { "identity": 3, "image": 2, "volume": 2, } [1] https://docs.openstack.org/releasenotes/horizon/queens.html [2] https://docs.openstack.org/horizon/rocky/install/install-rdo.html Thanks, Massimo

2 2

[nova] instance breaks the affinity/anti-affinity of server group with force_hosts or force_nodes
by Boxiang Zhu 11 Apr '19

11 Apr '19

Hi All My openstack all-in-one environment is setup by devstack. I created a server-group with anti-affinity policy. Then an instance was created with this server-group successfully with command[1]. Another instance was also created with this server-group and with force_host successfully with command[2]. But if I did not specify the force_host, the instance failed to create[3]. I think the second instance had broken the anti-affinity server-group. So my question is that whether the result is within design scope or it is a issue and needs to be discussed : ) [1] nova boot <instance-name> --flavor <flavor> --image <image> --availability-zone <az> --security-groups <sec-group> --nic net-id=<net-id> --hint group=<server-group> [2] nova boot <instance-name> --flavor <flavor> --image <image> --availability-zone <az>:<host> --security-groups <sec-group> --nic net-id=<net-id> --hint group=<server-group> [3] nova boot <instance-name> --flavor <flavor> --image <image> --availability-zone <az> --security-groups <sec-group> --nic net-id=<net-id> --hint group=<server-group> Best Regards Boxiang

2 6

[tripleo] tripleoclient stable/stein is now branched
by Emilien Macchi 11 Apr '19

11 Apr '19

1) Make sure you do the backports to stable/stein as usual, when needed. 2) We'll branch the rest of TripleO projects once we know CI works fine on this branch and once we are sure no blockers hit current master. Thanks, -- Emilien Macchi

1 0

Re: [tricircle][heat] Tricircle or Trio2o
by Zane Bitter 11 Apr '19

11 Apr '19

On 1/08/18 12:55 PM, Andrea Franceschini wrote: > Actually a heat multisite solution would work too, but I cannot find > any reference to this kind of solutions. You can use the OS::Heat::Stack resource to create stacks in remote regions: https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::He… In Stein you can also use it to create stacks in remote clouds (note: requires Barbican in the local cloud, and of course Heat in the remote cloud). Full docs for that haven't landed yet but they're in review here: https://review.openstack.org/649220 cheers, Zane.

1 0

[sahara][ptg] Preliminary poll for scheduling Sahara virtual PTG
by Jeremy Freudberg 11 Apr '19

11 Apr '19

Hello Saharans and other interested parties: For the Train cycle our PTG will only be virtual. I have assembled here some possible days on which to hold the virtual PTG: https://doodle.com/poll/228ppwvqg488n3c5 We'll probably meet for about 2 hours on Bluejeans (DESPITE the poll the showing huge chunks of time). There'll be an Etherpad and outcomes will be logged to this mailing list too. All are welcome. Best, Jeremy

1 1

RuntimeError: OVS transaction timed out - After minor upgrade
by Yedhu Sastri 11 Apr '19

11 Apr '19

Dear All, We did a minor upgrade on our OpenStack environment Newton HA cluster from 14.2.12 to 14.2.16 using the following link. https://docs.openstack.org/openstack-ansible/newton/upgrade-guide/minor-upg… The upgrade was successful and we tested creation of VM's and it was also successful we were able to ssh into the VM's. Then we rebooted the controllers one by one. But after that we can create the VM's but it is not getting IP from dhcp agent. In the openvswitch-agent.log we are getting 'OVS transaction timeout'. Any help is much appreciated. 2019-04-09 17:25:29.063 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.088 3504 INFO neutron.agent.common.ovs_lib [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 04275c8a-2d12-477b-b435-f6483d418e93 not present in bridge br-int 2019-04-09 17:25:29.089 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.198 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.228 3504 INFO neutron.agent.common.ovs_lib [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 5c25b580-9dcb-4930-a2fe-9cab951114dd not present in bridge br-int 2019-04-09 17:25:29.228 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] port_unbound(): net_uuid None not managed by VLAN manager 2019-04-09 17:25:29.229 3504 INFO neutron.agent.securitygroups_rpc [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Remove device filter for [u'63cb0c6a-6e82-41a8-ad46-511ee84579ad', u'9764e98a-bb32-4d37-9460-5a546f351e5a', u'2c075f29-156c-4787-b40f-434c437164e4', u'f00de46f-301a-4789-add1-a8239ee6c859', u'e26c1806-8041-4ce2-aea0-74ca469add67', u'9fa17447-d25d-441b-9983-b81e43c6e6d2', u'3ef24ce6-19b5-47c8-9510-767e64d33e9f', u'c2d37add-65a0-4fc9-914c-2382af70b1ca', u'a8b7c7aa-a5d0-47b3-a944-7b6c4428eda8', u'bf6f7608-0573-43f7-822a-878d7708d985', u'046670cd-77dd-4ce8-bb4b-f1489264375b', u'b7aefa18-d768-47a8-bb5f-6b1e838deaeb', u'04275c8a-2d12-477b-b435-f6483d418e93', u'124eb5e6-2b8a-44a9-aa8b-f6d9bc87f13f', u'5c25b580-9dcb-4930-a2fe-9cab951114dd'] 2019-04-09 17:27:09.740 3504 INFO neutron.agent.securitygroups_rpc [req-5984df4b-c30f-403c-8e87-86c4ccf50a9f - - - - -] Provider rule updated 2019-04-09 17:27:41.961 3504 INFO neutron.agent.securitygroups_rpc [req-67c36a44-f778-48f0-b7ae-0a5244ff95c1 - - - - -] Provider rule updated 2019-04-09 17:28:28.334 3504 INFO neutron.agent.securitygroups_rpc [req-aeffc24f-a354-412e-b458-950c1d4b52ef - - - - -] Provider rule updated 2019-04-09 17:28:46.276 3504 INFO neutron.agent.securitygroups_rpc [req-2dd51325-40c4-4ff0-a384-bccbe3ca0bfc - - - - -] Provider rule updated 2019-04-09 17:28:46.278 3504 INFO neutron.agent.securitygroups_rpc [req-6d48bfd9-0230-4a82-a477-d9e4171db519 - - - - -] Provider rule updated 2019-04-09 17:30:32.695 3504 INFO neutron.agent.securitygroups_rpc [req-01b9b7a8-84a4-42cc-aebb-db846eb2b8f0 - - - - -] Provider rule updated 2019-04-09 17:30:54.288 3504 INFO neutron.agent.securitygroups_rpc [req-de1755bd-0e21-4b75-9fde-db422ee9a79a - - - - -] Provider rule updated 2019-04-09 17:32:12.377 3504 INFO neutron.agent.securitygroups_rpc [req-26bc4547-edb7-4092-b4f4-6465c29dfbe4 - - - - -] Provider rule updated 2019-04-09 17:32:21.444 3504 WARNING neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Device 0d535260-dd98-4027-a2ba-4c5412d4eab0 not defined on plugin or binding failed 2019-04-09 17:32:21.461 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port d3baa557-a367-4a6d-8d58-7183df4243a6 updated. Details: {u'profile': {}, u'network_qos_policy_id': None, u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id': u'680c9bdd-9cea-4059-8c8c-2928dd0ee48f', u'segmentation_id': 65606, u'device_owner': u'network:router_ha_interface', u'physical_network': None, u'mac_address': u'fa:16:3e:b3:9a:60', u'device': u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'port_security_enabled': False, u'port_id': u'd3baa557-a367-4a6d-8d58-7183df4243a6', u'fixed_ips': [{u'subnet_id': u'5b49f8e5-991d-4ecd-a584-df605063aecb', u'ip_address': u'169.254.192.9'}], u'network_type': u'vxlan'} 2019-04-09 17:32:21.461 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 1 as local vlan for net-id=680c9bdd-9cea-4059-8c8c-2928dd0ee48f 2019-04-09 17:32:35.477 3504 INFO oslo_messaging._drivers.amqpdriver [-] No calling threads waiting for msg_id : a9314d944ff8486abf909d4cc271f9a0 2019-04-09 17:32:39.016 3504 INFO neutron.agent.securitygroups_rpc [req-51453b2c-b454-45bd-b7f8-c78560437016 - - - - -] Provider rule updated 2019-04-09 17:32:54.141 3504 ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Switch connection timeout 2019-04-09 17:32:57.964 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ovs_bridge [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Bridge br-tun changed its datapath-ID from 6a740a5da349 to 00006a740a5da349 2019-04-09 17:32:58.015 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 0d8dc3c9-c115-45f8-bbb2-cc715b7c1079 updated. Details: {u'profile': {}, u'network_qos_policy_id': None, u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id': u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625, u'device_owner': u'network:router_gateway', u'physical_network': u'outbound1', u'mac_address': u'fa:16:3e:aa:d7:56', u'device': u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'port_security_enabled': False, u'port_id': u'0d8dc3c9-c115-45f8-bbb2-cc715b7c1079', u'fixed_ips': [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address': u'10.97.179.34'}], u'network_type': u'vlan'} 2019-04-09 17:32:58.016 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Assigning 2 as local vlan for net-id=4ffb2c28-f9f1-4a25-82a0-df7f7a002434 2019-04-09 17:32:58.030 3504 INFO neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Port 1239fa6c-265a-4f16-ab00-c86fe40545d9 updated. Details: {u'profile': {}, u'network_qos_policy_id': None, u'qos_policy_id': None, u'allowed_address_pairs': [], u'admin_state_up': True, u'network_id': u'4ffb2c28-f9f1-4a25-82a0-df7f7a002434', u'segmentation_id': 625, u'device_owner': u'network:router_gateway', u'physical_network': u'outbound1', u'mac_address': u'fa:16:3e:4d:73:46', u'device': u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'port_security_enabled': False, u'port_id': u'1239fa6c-265a-4f16-ab00-c86fe40545d9', u'fixed_ips': [{u'subnet_id': u'764f08fc-1979-402c-b93c-834d7148a8a5', u'ip_address': u'10.97.179.99'}], u'network_type': u'vlan'} 2019-04-09 17:33:13.289 3504 ERROR neutron.agent.ovsdb.impl_idl [req-04b10d7a-3f2c-4eda-8d86-c36f994323d9 - - - - -] Traceback (most recent call last): File "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/native/connection.py", line 117, in run txn.results.put(txn.do_commit()) File "/openstack/venvs/neutron-14.2.16/lib/python2.7/site-packages/neutron/agent/ovsdb/impl_idl.py", line 91, in do_commit raise RuntimeError(_("OVS transaction timed out")) RuntimeError: OVS transaction timed out -- With kind regards, Yedhu Sastri

2 2

[nova] indices on shadow-able fields
by Mohammed Naser 11 Apr '19

11 Apr '19

Hi everyone. In continuing with the trend of interesting database issues, I've found the following interesting thing. It looks like we don't have indices for all of our tables that can be large on the deleted field. I think it would be beneficial *especially* for cases when the archiving code runs. The big ones that are huge users in terms of rows without index are `instance_system_metadata` and `instance_extra`. `instance_action_events` and `instance_actions` don't have any either. I believe without this, it results in doing a full table scan during the clean up which can become pretty resource intensive. I'll defer to the Nova team on the best practice about this (or if this is even a bug), but I just wanted to bring the attention to this as I've had mild success trying to tame a large database and leveraging the archive DB tooling. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

4 4

[placement] Virtual Pre-PTG
by Chris Dent 11 Apr '19

11 Apr '19

We decided in today's placement meeting [1] that because of limited time and space at the PTG and conflicting responsibilities of the participants we'd like to prepare ourselves to only talk about things at the PTG that we weren't otherwise able to decide beforehand, in email. I've committed to orchestrating and then summarizing several conversations through a series of email threads based on the topics we choose. To do that, we need to make sure that the etherpads [2,3] reflect the important topics a few weeks before the PTG, so we can have enough time to talk. I propose we start the process the week of the 8th, giving us 3 weeks of discussion prior to the PTG, with the caveat that the week of the 22nd my availability will be limited. Between now and then make sure you topics get on the etherpads, along with as much additional info as you would normally put there. Don't fret if you think of something after the 8th, just put it on the etherpad as normal, and we'll figure it out. If the 8th is too soon or too late, please propose an alternative. If there's no need to change, I'll get things rolling on the 8th. This way the time at the PTG can be spent more oriented to reviewing our progress thus far and talking about how we can best achieve our goals in the future. Thanks [1] http://eavesdrop.openstack.org/meetings/placement/2019/placement.2019-03-25… [2] https://etherpad.openstack.org/p/placement-ptg-train [3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 4

[telemetry][gnocchi] Gnocchi alternatives
by Trinh Nguyen 11 Apr '19

11 Apr '19

Hi team, Yesterday, we talk about Gnocchi and how it is embedded in many parts of Telemetry these days [1]. Since we many things in Ceilometer have been replaced by Gnocchi which is an external project, we need the project to be sustainable at some point. I'm not sure about that since the Gnocchi's cores change jobs recently (?). So, I continue here the discussion on whether or not to find alternatives for Gnocchi. People have suggested: - Prometheus: we then can get rid of AODH and use Prometheus's Alert Manager - InfluxDB (part of Monasca): and because many parts of Monasca can do what Ceilometer/AODH doing we can possibly replace Telemetry completely (?) Correct me if I'm missing something. All ideas are welcomed. Yours, [1] https://etherpad.openstack.org/p/telemetry-train [2] http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-… -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

4 3

[sdk][ansible][inventory] Server-side filtering capability for nova API
by Игорь Тиунов 11 Apr '19

11 Apr '19

Hi. I saw that there some work regarding filtering in the inventory module. Also, I looked at how it will be used in future versions of ansible (os_server_facts module). I am worried about client-side nature of this filtering. The large deployments can have thousands of vms in one openstack project and such an environment can be very dynamic (vms are created/deleted frequently). The inventory collection can be done from multiple ansible management nodes and all these facts can lead to significant performance impact not only on the client side but on the server side also - a large amount of data will be requested from nova api servers. I want to propose the usage of server-side filtering capability for nova API: https://developer.openstack.org/api-ref/compute/?expanded=list-servers-deta… These filters are used at database level and will add a significant performance boost during inventory collection. I want to propose the usage of filters in ansible openstack inventory plugin but first, such filters should be implemented in openstacksdk level. I suggest splitting filters into two parts - the api_filters and metadata_filters. The api_filters will be used for server-side filtering and metadata_filters for client-side filtering. I have created the snippet with prototype code. There a _split_filters method and related changes for list_hosts and search_hosts methods: https://gist.github.com/ITD27M01/01bc73120bb97b237f53fa418dc83629 What do you think?

2 2

[telemetry] Procedure for merging patches
by Trinh Nguyen 11 Apr '19

11 Apr '19

Hi team, One of the thing that has been brought up in the last meeting is what is the process of merging a patch. So, let's try this first: - For small patches (e.g., change strings, fix typos, update docs): any core can approve for merging. - For a patch that implements a new feature, removes a feature, patch that has huge changes (in the number of changed files and loc, etc.) or any patch that is in doubt: we need at least 2 cores to give a +2 and then the PTL will merge it. Of course, we can change the procedure when we see issues. For now, this should be a guideline for the team. Please feel free to comment. Yours, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 3

[auto scaling sig][ptg][senlin][heat]
by Duc Truong 11 Apr '19

11 Apr '19

Everyone, Since the summit and PTG are coming up, I have updated the auto scaling SIG etherpad [1] with some topics. Please fill in if you are planning to participate and any other topics you would like to discuss. Duc (dtruong) [1] https://etherpad.openstack.org/p/DEN-auto-scaling-SIG

1 0

[nova] Pre-PTG spec review day(s)
by Eric Fried 11 Apr '19

11 Apr '19

Dear Nova spec authors and reviewers- Since our PTG time is shorter than usual this cycle, and we usually run out of time before we finish our agenda anyway, I would like to try to get as much spec review work wrapped up as possible before Denver. To that end, I would like to propose at least one spec review day over the next couple of weeks. This will be a chance for authors and reviewers to interact in a more synchronous fashion and hopefully let us close on some of the more significant issues. Can we do this next Tuesday, April 9th; and if necessary (and seeming productive) the following Tuesday, April 16th? If folks are amenable, I'll follow up with some logistics by the end of this week. Thanks, efried .

5 7

[dev][cinder][stable-maint] final os_brick release from stable/pike
by Brian Rosmaita 11 Apr '19

11 Apr '19

I just discovered that there was a bug in the dashboard I posted on today's Cinder meeting agenda, and this unmerged backport to stable/pike os_brick was left off: https://review.openstack.org/647809 The dashboard link, https://tiny.cc/cinder-stable-pike , now points to a correct dashboard (sorry about that, hemna!) Current status is: 2 backports +W and currently in recheck 2 backports with only one +2 - https://review.openstack.org/647745 - https://review.openstack.org/647743 1 backport without negative feedback - https://review.openstack.org/647809 There's one review not listed on the dashboard because it has a -W from its author, which I'm taking to mean it's not ready. But here's the link in case anyone wants to look: https://review.openstack.org/539359 We need to release the final pike os_brick soon, so prompt positive (or negative) attention from stable cores to the above will be appreciated. cheers, brian

1 0

[nova] Rebuild from cell0 limitation for personality files
by Matt Riedemann 11 Apr '19

11 Apr '19

I wanted to get some wider attention on what I think will be a limitation in the rebuild from cell0 spec [1]. The main idea in that spec is the user tries to create a server which fails during scheduling to find a host and puts the instance into ERROR state and "buries" it in cell0. With a new microversion, the user can attempt to rebuild the server from cell0 and go through scheduling again. This is part of a bigger effort to support pre-emptible instances where scheduling fails during server create, an external reaper service tries to make room by destroying some pre-emptible instances, and then the server gets rebuilt. The issue I've found is that if the server was created with personality files using microversion 2.1, fails, and then the user goes to rebuild it, their personality files will be lost because (1) we don't persist personality files anywhere, not even the RequestSpec and (2) microversion 2.57 deprecated the personality files parameter from the rebuild API [2]. Since you'll have to use a newer microversion > 2.57 to rebuild from cell0, you can't specify the personality files again. Are we OK with this? We deprecated personality files for a reason [3] so this is a natural extension of that deprecation saying "going forward you should not be using these things and if you do there could be limitations". The user has an obvious recourse: delete the server and re-create it rather than rebuild from cell0. I don't want to consider un-deprecating personality files in the rebuild API just for this new microversion to rebuild from cell0. Another alternative is persisting personality files in the RequestSpec but I'm not sure how much people would support that - although it would fix some other known limitations with personality files, like the fact that if you create a server with files and then shelve offload, the files are gone when you unshelve. I have a similar issue with cross-cell resize [4]. [1] https://review.openstack.org/#/c/648686/1/specs/train/approved/enable-rebui… [2] https://docs.openstack.org/nova/latest/reference/api-microversion-history.h… [3] https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/d… [4] https://review.openstack.org/#/c/642807/3/specs/train/approved/cross-cell-r… -- Thanks, Matt

3 2

OpenStack Stein is officially released!
by Sean McGinnis 10 Apr '19

10 Apr '19

The official OpenStack Stein release announcement has been sent out: http://lists.openstack.org/pipermail/openstack-announce/2019-April/002019.h… Thanks to all who were part of making the stein series a success. Really great to see how much the community was able to accomplish over this last cycle. This marks the official opening of the releases repo for Train. Stein is now a full stable branch. Thanks! Sean

2 1

[horizon] Proposing Vishal Manchanda (vishalmanchanda) for core
by Ivan Kolodyazhny 10 Apr '19

10 Apr '19

Hi everybody, I would like to propose adding vishalmanchanda to the horizon-core team. Vishal did a great contribution during the last six months both with commits [1] and reviews [2],[3]. He fixed a lot of bugs not only in a master branch but in stable branches too. Regular quality reviews during the last cycles show that he's on the same page with the rest of the team and understands the code base well too. If there are no objections, I'll add Vishal to the horizon-core team in a week. [1] https://review.openstack.org/#/q/owner:manchandavishal143%2540gmail.com+sta… [2] https://www.stackalytics.com/report/contribution/horizon-group/90 [3] https://www.stackalytics.com/report/contribution/horizon-group/180 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 1

[nova] "future" specs and blueprints
by Eric Fried 10 Apr '19

10 Apr '19

All- It seems like we don't have a great way of looking at a blueprint and saying, "this looks like a good idea, and yes we want to do it, but we're not going to be able to prioritize it for this release." Sometimes we just leave those blueprints "unspecified" and their specs stay open in limbo. And some blueprints we'll approve for the current series, and merge the spec under $current_cycle/approved, but not really intend to get the work completed. And at the end of the release, those pieces muddy our completion stats. It would be nice if those stats reflected only work we got done that we *intended* to get done. I'm not bringing this up just for the sake of making numbers pretty; it would just be nice to have a crisp picture of the work slated for the current release. And also a way for contributors to propose specs they *don't* intend for the current series, but still want to start discussing (I happen to know of at least one example of this for Train). And also a way to keep track of work we know we want to do eventually, just not now. === TL;DR >>> So I'd like to propose that we set up a "future" series in Launchpad, and a corresponding subdirectory in the specs repo. === TL;DR <<< The process would be pretty much as you would expect, including (but not limited to): - If we decide (e.g. at the PTG) that we like a spec that's proposed under $current/approved, but won't have time for it in the current series, we'll ask the author to move it to future/ and make sure the History section includes "$current: proposed and approved for 'future'". - If we decide in mid-release that we want to defer a blueprint, we can propose a patch to move it from $current/approved to future/ (including a redirect). - If a contributor wants to start work on a spec for a future release, they can propose it directly to the future/ path. - Every cycle when setting goals we can skim through the 'future' items to see if any should be pulled in. In which case we propose a patch to move the file from future/ to $current/approved (including a redirect) which we can fast-approve. - If we decide to flush a spec from 'future', we can move it to a 'rejected' (or 'abandoned'? bikeshed away) folder - but we can sort this part of the process out later. How do folks feel about this idea? -efried .

13 28

[Openstack-sigs][publiccloud-wg] Reminder weekly meeting Public Cloud WG
by Tobias Rydberg 10 Apr '19

10 Apr '19

Hi everyone, Time for a new meeting for the Public Cloud WG - tomorrow (11th) 1400 UTC in #openstack-publiccloud! Agenda can be found below and at https://etherpad.openstack.org/p/publiccloud-wg Agenda 1. Expose WGs and SIGs 2. Migrating to SIG 3. Planning Summit and PTG - Meeting room at the PTG - Thursday morning - Update status / content in https://launchpad.net/openstack-publiccloud-wg - Select most important 4. Other topics Talk to you tomorrow! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

[masakari][Release-job-failures] Tag of openstack/masakari failed
by Sean McGinnis 10 Apr '19

10 Apr '19

There were a couple of release note publish failures today for the masakari and masakari-monitors repos. They were due to these repos still using oslosphinx in their docs and releasenotes jobs. With the release of Sphinx 2.0 last week, oslosphinx no longer compatible. All projects should now be using openstackdocstheme and there are no plans to update oslosphinx to work with the new Sphinx version. The following will need to be merged to get these jobs working again. openstack/masakari https://review.openstack.org/651516 openstack/masakari-monitors https://review.openstack.org/651518 Thanks! Sean ----- Forwarded message from zuul(a)openstack.org ----- Date: Wed, 10 Apr 2019 12:20:14 +0000 From: zuul(a)openstack.org To: release-job-failures(a)lists.openstack.org Subject: [Release-job-failures] Tag of openstack/masakari failed Reply-To: openstack-discuss(a)lists.openstack.org Build failed. - publish-openstack-releasenotes-python3 http://logs.openstack.org/31/3191a411fb823913ddfed43e9c44d4e163992ebb/tag/p… : FAILURE in 4m 38s _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures ----- End forwarded message -----

1 0

[all] Removing privacy breaches in doc
by Thomas Goirand 10 Apr '19

10 Apr '19

Hi, In may docs, I can see stuff like this, especially in README.rst: .. image:: http://governance.openstack.org/badges/something.svg :target: http://governance.openstack.org/reference/tags/index.html I'd like to let everyone know that, from a package maintainer perspective, and considering that we do package your Sphinx doc in distros, this is an annoyance. Indeed, I do feel like I must patch it out and remove the external source. The reason is, as a Debian user, I do not expect my browser to do external queries to a website when I'm browsing a local documentation. This one is on openstack.org, it's mildly ok-ish, though, I'm removing the image still. There's other more annoying stuff (think: travis, github, and other spies which we don't control). So, it'd be nice if these images with external resources were completely avoided in OpenStack docs. Either by simply not putting such useless image, replacing it by text only, or by embedding the image itself in the doc (or in openstackdocstheme? I suspect that's not what people want, they want it to be displayed in github... so embedding would be the only solution). Cheers, Thomas Goirand (zigo)

8 19

[placement][nova][ptg] NUMA Topology with placement
by Chris Dent 10 Apr '19

10 Apr '19

>From the cross-project etherpad [1] * Spec: https://review.openstack.org/#/c/552924/ This is probably the biggest topic, in the sense that modeling NUMA in placement and how we do that has a big impact across a large number of other pending features, including several specs that state things like "this would be different if we had NUMA in placement". Similarly, if we do have NUMA in placement, we also end up with questions about and requirements with: * json payload for getting allocation candidates: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004724.ht… * increased complexity in protecting driver provided traits http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004779.ht… * resource provider - request group mapping http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004819.ht… * resource providers with traits but no resources http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004817.ht… * resource provider (subtree) affinity http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004782.ht… And there's probably cascades over to dedicated cpus, cpu capabilities, network bandwidth mgt, etc etc. >From the placement perspective, the problem isn't representing the NUMA info in placement, it's getting candidates back out in a useful fashion once they are in there, so the resources can be claimed. It would be useful if someone could make explicit and enumerate: * What (if any) ways in which the current handling of nested providers does not support _writing_ NUMA-related info to placement. * What (we know there are some) ways the current handling of allocation candidates and the underlying database queries do not support effective use of NUMA info once it is in placement. Thanks. [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[placement][nova][ptg] Testing PlacementFixture effectively
by Chris Dent 10 Apr '19

10 Apr '19

>From the cross project etherpad [1] -=-=- * We've had two instances where nova functional tests have failed from what seems like an unrelated change in placement, but turns out to be something that impacts the behavior of the PlacementFixture, from placement, used by nova. Would be good to decide on a way to make this safer without having to run the entire nova functional test suite (and the functional suite of every other project that eventually uses the Fixture) on every placement change. Maybe a subset somehow? Or some other kind of magic? Another option may be what we've been doing: fixing problems as they come up. That might be OK. * https://bugs.launchpad.net/nova/+bug/1818560 * https://bugs.launchpad.net/nova/+bug/1821092 * (gibi): Currently placement patches trigger grenade-py3 and tempest-full-py3 and both jobs takes around an hour to run. The nova-tox-functional test runs in about 20 minutes. So triggering nova-tox-functional for placement patches does not increase the length of the CI feedback loop. * True but the total cpu cost of testing a single placement patch is a thing we need to keep in mind. Zuul resources are scarce. It's not just how long we have to wait, but how long everyone has to wait for all patches. (Not saying we shouldn't do it, just that we need to consider that impact.) (gibi): I agree that overall cpu cost is a factor here. * [efried] ++ I think this is a solid idea, at least until we implement the next bullet. * (gibi): Both above bug could be detected with some test on the placement side using the PlacementFixture in a way nova is using that fixture. It might not be easy to gather all the relevat usage patterns. * [efried] Agree with this. We don't have any testing of PlacementFixture in placement itself (until the below) * [efried] Started simple unit testing here https://review.openstack.org/#/c/645255/ * This probably doesn't do us much good wrt preventing weird gatebusters like the above. -=-=- This is generally agreed to be an issue we need to address and there are ideas for how to fix it, so the things to resolve here are: * Tuning the ideas to the best combination. * Figuring out who is going to do it. [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tripleo][openstack-ansible] collaboration on os_tempest role update XVIII - Apr 10, 2019
by Chandan kumar 10 Apr '19

10 Apr '19

Hello, Here is the 17th update (Apr 03 to Apr 09, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * os_tempest doc build job was broken and bug in generate test-list file task are got fixed * we have added tempest_services var to automatically enable tempest_service_available_{project_name} var. * os_tempest got support of debian distro. * We have added required os_tempest vars in tripleo CI in order to port periodic rdo third party job to os_tempest. Thanks to Arx for tempest_test_whitelist featureset overrides, mnaser for adding debian support and fixing doc job builds across OSA, jrosser, odyssey4me, noonedeadpunk for helping on tempest_services patch. Things got merged: os_tempest * docs: drop sphinxmark - https://review.openstack.org/649859 * Fix Generate test-list file task - https://review.openstack.org/649604 * debian: add support - https://review.openstack.org/650499 * tempest_services var for setting tempest_service_available_{} - https://review.openstack.org/649577 tripleo * Add tempest_test_whitelist to allowed_override - https://review.openstack.org/#/c/648110/ * Remove the tempest_test_whitelist from playbook - https://review.openstack.org/#/c/648111/ * tempest_services var for setting tempest_service_available_{} - https://review.openstack.org/649577 * Include vars of tempest_services and concurrency in fs override - https://review.openstack.org/649553 Things in Progress: os_tempest: * os_tempest user guide: https://review.openstack.org/#/c/644570/ * Switch to import_task in os_tempest - https://review.openstack.org/650054 tripleo * Update Standalone Periodic jobs in Master to use OS_TEMPEST - https://tree.taiga.io/project/tripleo-ci-board/us/972 What is coming? * We are working on porting standalone periodic jobs to os_tempest on RDO side * FInishing Doc user guide Here is the 17th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004492.ht… Thanks, Chandan Kumar

1 0

[placement][nova][ptg] Use in_tree getting allocation candidates
by Chris Dent 10 Apr '19

10 Apr '19

>From the (cross-project) etherpad [1]: -=-=- * Spec: https://review.openstack.org/#/c/646029/ * Branch: https://review.openstack.org/#/q/topic:bp/use-placement-in-tree * -> This spec and branch proposes to translate [user specified host/node] into [compute node uuid] internally in nova before asking to placement * Discussion point: What to do when an operator specifies only "forced_host" in VM creation with --availability-zone and multiple nodes are found in the DB 1. We use this optimization only when 1 node is found in the nova side DB. Skip this optimization otherwise. 2. We use this optimization whenever possible passing every found compute node uuids. 3. We use this optimization when smaller amount than N node are found in the nova side DB. Skip this optimization otherwise. 3-1. appropriate N value (or the "default" N value) in terms of <REST query string length> and <DB query with IN clause> 4. Others? * Note: Option 2 and 3 needs a change in placement side REST API to accept multiple uuids in the `in_tree` query * Spec: https://review.openstack.org/#/c/651113/ -=-=- >From a placement perspective the main discussion point here is the placement side spec at [2] which is relatively straightforward and low impact: making an existing query parameter more expressive while keeping existing response format. There's some questions (on the spec) about the details of the syntax. There's also a concern about query string length but that's discussed above. [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement [2] https://review.openstack.org/#/c/651113/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

Test
by M Ranga Swami Reddy 10 Apr '19

10 Apr '19

1 0

[scientific-sig] Meeting today, 1100UTC: Ironic and external DCIM, Denver preparation
by Stig Telfer 10 Apr '19

10 Apr '19

Hi All - We have a Scientific SIG IRC meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_10th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_10th_2019> The plan is to cover some recent discussions on improving integration of Ironic with external data centre inventory management systems. Plus, we have some CFPs for ISC 2019 and plenty to plan for the Denver summit besides. Cheers, Stig

1 0

Re: [tc][telemetry] Asking core privileges on Telemetry projects
by Trinh Nguyen 10 Apr '19

10 Apr '19

Thanks. Got it. On Wed, Apr 10, 2019 at 4:44 PM Andreas Jaeger <aj(a)suse.com> wrote: > On 10/04/2019 08.50, Trinh Nguyen wrote: > > Hi Jens, > > > > I just see I'm not in the list of these following groups on gerrit: > > > > ceilometer-release > > aodh-release > > panko-release > > > > Could you please add me to those as well? > > You don't need to be - releases are done via the releases repo. > > Those groups are completely unused currently, > > Andreas > -- > Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter: jaegerandi > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah > HRB 21284 (AG Nürnberg) > GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 > > -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[releaseteam] Changing the meeting time.
by Tony Breeds 10 Apr '19

10 Apr '19

Hello all, Now that the world has completed it's biannual calendar confusion dance, and Stein is pretty darn close to being released. I'd like to move the release team meeting to a time I can attend[1] It's going to be hard to find a time that works for the whole team given out 'follow the sun' support model. IIUC we have[2]: * Australia * Europe * US East * US Central * US West Which means someone (or some people) are going to be inconvenienced. If needed, we could do 2 meetings one for AU+EU and then another for AU+US but I'd much rather have a single meeting to keep everyone on the same page. I've created a doodle poll: https://doodle.com/poll/xxa46wrndefyi6dk I picked Thursday as the day of the week for the poll but if if needed we can mov it to another day. Yours Tony. [1] The current meeting time is 0200 for me. [2] https://www.worldtimebuddy.com/?pl=1&lid=21,312,5,8&h=21

4 6

[Watcher] Team meeting
by li.canwei2＠zte.com.cn 10 Apr '19

10 Apr '19

Hi , We will have the team meeting today at 08:00 UTC on #openstack-meeting-alt IRC channel. The meeting agenda at https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda#04.2F10.2F2019 Thanks, Canwei Li

1 0

[First Contact] New Meeting time!
by Kendall Nelson 10 Apr '19

10 Apr '19

Hello! Probably should have sent this sooner, but better late than never? Our first meeting at the new time is today in about a half hour at 1:00 UTC in the #openstack-upstream-institute channel. Hope to see you there! -Kendall Nelson (diablo_rojo)

1 0

[trove] Trove CI and review
by Lingxian Kong 10 Apr '19

10 Apr '19

Hi team, You may have noticed that after we migrating the trove CI job to Ubuntu Bionic, there are some non-voting jobs keep failing because of some inconsistency issues or incompatible installations inside the guest agent image. I have been working on the fix, but would appreciate if any of you could offer some help, especially if you care about the database types relating to those failed jobs. Additionally, as the team core reviewers, please keep review, or at least leave some comment on the patches showing that you are interested but don't have time at the moment. Be aware of that, given the current situation of review activities in the project, it's acceptable for only one core reviewer to merge patches, especially those trivial ones such as CI fixes, documentation, etc. Thanks! --- Lingxian Kong Catalyst Cloud

1 0

[telemetry] Telemetry for Train
by Ranganath, Sunku 10 Apr '19

10 Apr '19

Hi Trinh, I work in cloud telemetry area. Followed through the mailing list, IRC chat and the etherpad. I see most folks participating are from Asia or EU. Is there a way that these meetings could be conducted in USA friendly time zone? Possibly have it biweekly in alternating time zones. Thanks for taking this up. Thanks, Sunku Ranganath

2 2

[PTG][Forum] Wikis for Collecting Etherpads
by Kendall Nelson 10 Apr '19

10 Apr '19

Hello Everyone! Since we are creeping closer and closer to the Summit + PTG, I'm circulating these wikis so we can collect all the etherpads being started/filled. Forum etherpads[1] PTG etherpads[2] -Kendall Nelson (diablo_rojo) [1]https://wiki.openstack.org/wiki/Forum/Denver2019 [2]https://wiki.openstack.org/wiki/PTG/Train/Etherpads

1 0

[tripleo] removal of mixed release config files used in upgrades
by Sorin Sbarnea 09 Apr '19

09 Apr '19

Hi! As part of the release config cleanup/sanitization we have a change for removal of mixed release files https://review.openstack.org/#/c/650913/ <https://review.openstack.org/#/c/650913/> D config/release/master-undercloud-ocata-overcloud.yml D config/release/ocata-undercloud-newton-overcloud.yml D config/release/queens-undercloud-newton-overcloud.yml D config/release/tripleo-ci/CentOS-7/master-undercloud-queens-overcloud.yml D config/release/tripleo-ci/CentOS-7/master-undercloud-rocky-overcloud.yml D config/release/tripleo-ci/CentOS-7/pike-undercloud-ocata-overcloud.yml D config/release/tripleo-ci/CentOS-7/queens-undercloud-newton-overcloud.yml D config/release/tripleo-ci/CentOS-7/queens-undercloud-pike-overcloud.yml D config/release/tripleo-ci/CentOS-7/rocky-undercloud-queens-overcloud.yml AFAIK, emit releases script changes removed the need for having these mixed files, so it should be safe to remove them. Feel free to add your comments on that change as we would like to avoid breaking a job that may be still needing them -- we tried to identify jobs using them, even on queens and rocky branches but so far we did not find any job still using these files (the upgrade ones are using standard release files and emit releases). PS. The reason for removal of these files is that we are trying to add some validation of the release config files, and those were found as containing some invalid data. Thanks Sorin Sbarnea

1 0

[OSSA-2019-002] Unable to install new flows on compute nodes when having broken security group rules (CVE-2019-10876)
by Gage Hugo 09 Apr '19

09 Apr '19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 =========================================================================================== OSSA-2019-002: Overlapping security group rules prevents compute node network configuration =========================================================================================== :Date: April 08, 2019 :CVE: CVE-2019-10876 Affects ~~~~~~~ - - Neutron: >=11.0.0 <11.0.7, >=12.0.0 <12.0.6, >=13.0.0 <13.0.3 Description ~~~~~~~~~~~ Diko Parvanov (Canonical) reported a vulnerability in neutron- openvswitch-agent security group rules. By creating two security groups with separate/overlapping port ranges, an authenticated user may prevent neutron from being able to configure networks on any compute nodes where those security groups are present. All neutron deployments utilizing neutron-openvswitch-agent are affected. Patches ~~~~~~~ - - https://review.openstack.org/648102 (Pike) - - https://review.openstack.org/648004 (Queens) - - https://review.openstack.org/648003 (Rocky) - - https://review.openstack.org/648002 (Stein) - - https://review.openstack.org/640252 (Train) Credits ~~~~~~~ - - Diko Parvanov from Canonical (CVE-2019-10876) References ~~~~~~~~~~ - - https://launchpad.net/bugs/1813007 - - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10876 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEWa125cLHIuv6ekof56j9K3b+vREFAlysvccACgkQ56j9K3b+ vREj3BAAvVBLfJT/cOyk2VjXjvlNKBWs1uokNE5PwzT0M2kvEW42zG78JpJj9EyJ ONQMCiuclWJ6XcBLBhDG2MHzl31Rqnfhi1UxQoUPwZYtgTcokLa4NaGCQUMrRwpq vigC8zWA9SiIQBHp4b/HE1ZA0GCKgK5CS2OuqmQH25/AzIDqwZZ7ljstRMh28VDd PnorJwifeKq1uUL1AGRWmDUvfYaqzTbMxNlUcrXt2Iy50VLxdokmD+PtZMLvb7lq UcpJ7R/er6HipNDE42hNzQAgEoPBNJ3hwEiLU64ZPCxSCMeKos5d2yAPNwLUYwdm lVYJQtW1GkNDLvY37pHOFzFCK2XhjKQB29iZjz5ipC9EKs1HLnxCfJfvIS+bK3Bt c3R0frUOOiDPeP+so1edl1f0eZJlhzV3SlFsLfLfFa1BYTxj6uuQdSaPaOTCGaLN 4TLAtysGl+USvXirOH+F/vuz9P0LOlL4f86/gwNY9Asb27MmKZFtUhQLux/k34Xg gwSFtWTKqLJWrZjlGL/9irh6PiS6myrPCxsYh8XXOpVHSw5D353NrZ3hapvUthA6 BoArm9XxRlwzgu8JwXpEAc9FXRg3jUcwMrSYc5yZF4mw95+sfdHKVhoI6LuxBkYd dA0aqbB/QkuFSanDZ+Z634LCkfbk/2Eo3HgjsrPUdvg2z2zLwfk= =53iD -----END PGP SIGNATURE-----

1 0

How to protect plain-text passwords in local.conf
by Akhil Jayakumar (akjayaku) 09 Apr '19

09 Apr '19

Hi Folks, Is there a way we can encrypt passwords in local.conf? If so could you please point me to the reference? Thanks, Akhil.

3 2

resize a vm to a flavor with pci-passthrough
by Manuel Sopena Ballesteros 09 Apr '19

09 Apr '19

Dear Openstack community, I have 1 physical node with x4 nvidia nv100 running 1 fat vm. Additionally I am adding a nvme drive into that host and I would like to attach the nvme drive to the vm. Ideally I prefer to avoid data migration and redeploy the software. My problem is that I don't have another host with gpus so I am guessing that the vm can't be migrated. Am I right assuming this? So far I thought about 2 possibilities but I don't know whether they would work: Option 1: crate a new flavor with the pci device pass-through and resize existing vm (I hope the new vm with the new flavor will have the nvme attached). Option 2: convert ephemeral virtual disk into a bootable volume. Destroy vm. Create new vm with the new volume as a boot device. Which option would be preferred? Is there any other think I can do? Thank you very much Manuel NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

4 4

[tripleo] CI Community Meeting time changed
by Rafael Folco 09 Apr '19

09 Apr '19

The CI Community Meeting (office open hours) has been moved to 13:30 UTC (30 minutes before the TripleO meeting). *MEETING TIME: Every Tuesday at 13:30 UTC* in https://bluejeans.com/4113567798. Agenda: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting --rfolco

1 0

[trove] Propose changes of the core team
by Lingxian Kong 09 Apr '19

09 Apr '19

Hi team, According to the community recommended criteria when removing cores[1] and the recent 3 months review statistics[2][3], as Trove PTL of the Train dev cycle, I propose the following change to the team: Members to remove from core team: Luke Browning Maciej Jozefczyk Manoj Kumar Nikhil Manchanda Samuel Matzek Yao Wang Zhao Chao jian.song zhanggang Thanks for all of your contributions to Trove, you are all welcomed to come back to the team anytime when the situation changes. All Trove core members, please respond with your comments and objections. [1] https://docs.openstack.org/project-team-guide/ptl.html#criteria-when-removi… [2] https://www.stackalytics.com/report/contribution/trove/180 [3] https://www.stackalytics.com/report/contribution/python-troveclient/180 --- Lingxian Kong Catalyst Cloud

2 1

[telemetry] Telemetry for Train
by Trinh Nguyen 09 Apr '19

09 Apr '19

Hi team, As we discussed last time [1], the Telemetry team needs help to maintain its projects in Train. I and Lingxian Kong [2] will give it a try this cycle hopefully will keep Telemetry as healthy as possible. I would like to kick start Telemetry in Train by calling for a team meeting this week to figure out what really happening and plan for actions in Train. - IRC Channel: #openstack-telemetry - Time: TBD (dangtrinhnt UTC+9) - Discussion etherpad (put your name to the attendee list): https://etherpad.openstack.org/p/telemetry-train Please reply here or ping me on the IRC channel (dangtrinhnt) what your options are and we will set up the meeting. Moreover, I would like to ask the current core members of Telemetry to grant me and Lingxian Kong core reviewers privileges on all of the Telemetry projects on Gerrit (ceilometer, aodh, panko, etc.). Thanks and love to talk to you soon. Yours, [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003897.ht… [2] https://review.openstack.org/#/c/645122/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

4 13

CLOS networking support best practice?
by Syd Logan 09 Apr '19

09 Apr '19

Hi, Over the past few weeks I've experimented with neutron in search of an "ah-ha!" moment at which point I've discovered how to best to use OpenStack neutron to implement a large datacenter CLOS network that supports bi-directional traffic between tenants and the external network(s). While the exploration has been quite educational (and fun), I'm still not there, and looking for suggested compass heading(s) towards best practice(s) as of 2019. Back in 2015, a blog post http://www.dorm.org/blog/openstack-architecture-at-go-daddy-part-2-neutron/ suggests a certain amount of heavy lifing was needed to support GoDaddy's leaf-spine, but I'm hoping by now things might be supported a bit more "out of the box". If not, what is best approach, and what is missing that needs contribution in order to make it complete? TIA and Best, syd

1 0

[chef][stable] Chef OpenStack retiring stable branches
by Jens Harbott 09 Apr '19

09 Apr '19

The Chef OpenStack project still has a set of repos with stable/newton branches, however those have been announced as EOL for more than a year [0], but we missed to actually close them down. I plan to do so in a couple of days unless there is some justified objection. See [1] for a list of the affected repositories and the commit hashes that are targeted to receive the "newton-eol" tag. The situation with the stable/ocata branches is similar, but while we did announce them as EOL in [0], too, the date mentioned there seems wrong. Also, there seems to be some confusion about the situation for the global OpenStack project, which doesn't seem to have retired stable/ocata for any project yet. Still, we don't have any open patches for stable/ocata, we don't have a working CI for it, and there also isn't anyone using it known to me. So please respond if there is a reason to keep the stable/ocata branches in their current state, otherwise I'd start the process to tag them as EOL, too. Jens [0] https://docs.openstack.org/openstack-chef/queens/install/genealogy. html#releases-summary [1] https://review.openstack.org/649945

2 1

openstack-ansible AIO error : os_swift : Get md5sum of local builder files
by Dimitris Theoharis 09 Apr '19

09 Apr '19

Hello I have been trying to add SWIFT in AIO for some testing but i always get the error i will post below. I have tried Ubuntu bionic and Centos 7 and git cloned 18.1.4 , 18.1.6 , 19.0.0.0rc2 , master all versions give me the same error about SWIFT . As i understand the error may be an ansible bug but not quite sure . the bootstrap-ansible installs version 2.7.9 this is the error: TASK [os_swift : Verify md5sum of builder files] ******************************************************************************************************************************************************************************************************************************* skipping: [aio1] => (item=aio1) fatal: [aio1]: FAILED! => {"msg": "The conditional check 'hostvars[item]['builder_md5sum'] != md5sum.stdout' failed. The error was: error while evaluating conditional (hostvars[item]['builder_md5sum'] != md5sum.stdout): 'ansible.vars.hostvars.HostVarsVars object' has no attribute 'builder_md5sum'\n\nThe error appears to have been in '/etc/ansible/roles/os_swift/tasks/swift_rings_post_distribution_check.yml': line 24, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# As this is post sync all should match and not be empty\n- name: Verify md5sum of builder files\n ^ here\n"} here is a very detailed error log https://pastebin.com/7B2wgac4 any tips ? thanks Dimitris Theoharis DevOps Engineer w: auvious.com e: dimtheo(a)auvious.com

1 0

[PTG][nova][neutron][cyborg][placement][ironic][cinder] Cross-project PTG planning
by Eric Fried 09 Apr '19

09 Apr '19

All- Starting to plan for Denver, I'd like to get a feel for cross-project sessions involving Nova. I made a pass through the Nova etherpad [1] and started extracting the bits that were obvious cross-project topics with Neutron [2], Cyborg [3], and Placement [4]. In a couple of places where I wasn't sure I left `XPROJ?`. We usually also have cross-project sessions with Cinder and Ironic. I saw no obvious topics with which to seed those etherpads yet, but please do so as they arise. Similarly, if other project teams have topics to discuss with Nova, please create an etherpad and link it from the bottom of [1] and the wiki [5]. Looking at the room schedule [6], how do folks feel about earmarking Friday morning for cross-project sessions? As the etherpads fill up we'll hopefully get a better idea of how much time to schedule for each. And doing it relatively early gives us time to prioritize spillover for Saturday if that becomes necessary. <what is going on in Eric's head?> Why granular etherpads? I'm hoping it will be more manageable than the enormous monolithic etherpad we usually end up with. We often tend to split out some pieces on the fly anyway; just trying to anticipate the need. Besides, granular is my middle name. </what> Thanks, efried [1] https://etherpad.openstack.org/p/nova-ptg-train [2] https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron [3] https://etherpad.openstack.org/p/ptg-train-xproj-nova-cyborg [4] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement [5] https://wiki.openstack.org/wiki/PTG/Train/Etherpads [6] https://screenshotscdn.firefoxusercontent.com/images/8c880d0a-b41e-4cea-8ff…

6 5

[scientific-sig][ironic] Gathering datapoints - Ironic integration with data centre inventory management
by Stig Telfer 09 Apr '19

09 Apr '19

Hi All - Following some recent discussion with our friends at CERN, they are interested in gathering data, use cases and opinions about how Ironic could integrate with external DCIM tools. The idea is that Ironic’s essential node data could be enriched by being cross-referenced with lifecycle data, location, etc (and perhaps vice versa). We would like to bring some operator experience and Scientific SIG users tend to care for a broad base of hardware outside of their OpenStack estate. I might argue that Scientific SIG users stand to gain much from external integrations like this. Let’s put it on the agenda for this week’s IRC meeting (Wednesday 1100 UTC) and I hope people will come along with wish lists and constructive ideas that might be good input to help the CERN team gauge what good options might be. Cheers, Stig

1 0

Nodepool not able to register node to jenkins.
by Aman Kumar Sinha26 08 Apr '19

08 Apr '19

2 1

[networking-ovn] nested virtualization in ovn ci
by Guo, Ruijing 08 Apr '19

08 Apr '19

Hi, Does networking-ovn CI support nested virtualization? does it use OpenStack Infra? Do you have plan to add OVSDPDK in networking-ovn CI? I saw cpu flag vmx in 1) and didn't see vmx in 2). Why that? 1) http://logs.openstack.org/10/637510/2/check/networking-ovn-tempest-dsvm-ovs… 2) http://logs.openstack.org/65/643565/1/check/networking-ovn-tempest-dsvm-ovs… Thanks, -Ruijing

1 0

[release][kayobe] Release job failures
by Mark Goddard 08 Apr '19

08 Apr '19

Hi, We've had a few release job failures in Kayobe [1]. I created some new tags on stable branches last week, and the release jobs failed with the following: Unable to freeze job graph: Unable to modify final job <Job trigger-readthedocs-webhook branches: None source: opendev/base-jobs/zuul.yaml at master#112> attribute variables={'rtd_webhook_id': '74820', 'rtd_project_name': 'kayobe-release-notes'} with variant <Job trigger-readthedocs-webhook branches: None source: openstack/kayobe/zuul.d/project.yaml at master#2> It's not clear from the email which branch, tag or job this affects. The message above references our readthedocs job which aims to publish release notes, although I can't see the expected releases on tarballs.o.o or PyPI. The RTD release note Zuul job is defined here [2], is it causing a problem? We also use the docs-on-readthedocs template to update our docs. [1] http://lists.openstack.org/pipermail/release-job-failures/2019-April/001117… [2] https://github.com/openstack/kayobe/blob/44430a42421a7c59807a58cbbd67f90a15… Thanks, Mark

2 1

[PTL][release][stable] Pike transitioning to Extended Maintenance phase
by Sean McGinnis 08 Apr '19

08 Apr '19

Hey everyone, Thought I should get this out there to make sure folks are aware. We are actually overdue for Pike to have entered extended maintenance. According to the stable policy, that should happen 18 months after the release [0]. That means we should have made the switch in February, if my math is right. We will need to work through the details to actually put that in effect, but for now I wanted to remind teams that we do not do releases after a stable branch enters this phase. So this is a call for action for any teams that have been backporting fixes that time is short to get a final release out while you can. The release dates for each cycle can be found on the releases site [1]. Thanks! Sean [0] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… [1] https://releases.openstack.org/

4 7

[Magnum] x509: certificate signed by unknown authority
by Anirudh Gupta 08 Apr '19

08 Apr '19

Hi Team, I have deployed K8s cluster using Magnum Openstack Rocky Release. I have one master node and one slave node in my cluster. But when I try to create a POD on master node using the command *kubectl run nginx --image=nginx* My Container remains in ContainerCreating State. When I debugged into the issue, I found the below error *Warning FailedCreatePodSandBox 59s (x24 over 32m) kubelet, kubernetes-cluster-w6csm5uqyspz-minion-0 Failed create pod sandbox: rpc error: code = Unknown desc = failed pulling image "gcr.io/google_containers/pause:3.0 <http://gcr.io/google_containers/pause:3.0>": x509: certificate signed by unknown authority* However, in */etc/sysconfig/docker* file, I have disabled the gcr.io repository. OPTIONS='--insecure-registry="gcr.io,googleapis.com" --selinux-enabled ' The docker is successfully pulling the *gcr.io/google_containers/pause:3.0 <http://gcr.io/google_containers/pause:3.0> image,* BUT kubernetes is neither able to use local repository nor able to pull the image. Can someone please help me in resolving the *x509: certificate signed by unknown authority issue?* Regards Anirudh Gupta

1 1

fqdn magnum instances
by Ionut Biru 08 Apr '19

08 Apr '19

Hello, I was wondering if there is a way to set up the domain for template to use in order to have a FQDN hostname for all the vms that are part from the cluster Currently the name is: k8s-cluster-coreos-somerandomtext-minion-0 but i want something like k8s-cluster-coreos-somerandomtext-minion-0.mydomain.net I'm trying to resolve this: helm install stable/wordpress Error: forwarding ports: error upgrading connection: error dialing backend: dial tcp: lookup k8s-cluster-coreos-7pctbrnuykc6-minion-0 on 8.8.8.8:53: no such host

4 7

[trove] trove guest agent image building improvement
by Lingxian Kong 08 Apr '19

08 Apr '19

Hi team, I've proposed a patch https://review.openstack.org/#/c/650608/ for the image building improvement. The most significant change is introducing one more param `dev_mode` to the command so that users could choose to build image for non-dev environment. BTW, I've also submitted some other patches for CI improvement which need your review as well. Any suggestion or feedback are welcomed. --- Lingxian Kong Catalyst Cloud

1 0

[neutron] Bug deputy report (week starting on 2019-04-01)
by Bernard Cafarelli 08 Apr '19

08 Apr '19

Hello Neutrinos, I was the bug deputy for April Fools' week. All Critical/High bugs already have fixes merged, except https://review.openstack.org/#/c/650599/ (close to merge) Both Medium bugs would benefit from a second look (details below) A few invalid bugs, filled on LP while they should now be created on StoryBoard. This includes neutron-lbaas ( https://storyboard.openstack.org/#!/project/openstack/neutron-lbaas) and os-ken (https://storyboard.openstack.org/#!/project/openstack/os-ken not sure why it does not appear when searching for os-ken) Proposed RFE: * [RFE] L3 - netfilter Contrack Helper Support - https://bugs.launchpad.net/neutron/+bug/1823633 Suggested in L3 meeting Critical: * ml2 create_port_bulk produces incompatible port context to drivers - https://bugs.launchpad.net/networking-midonet/+bug/1822999 Midonet tests failing after bulk ports optimization merged Fixed with: https://review.openstack.org/#/c/649615 <https://review.openstack.org/#/c/649615/3> and https://review.openstack.org/649623 as added check * test_update_provider_net_unsupported failure - https://bugs.launchpad.net/networking-midonet/+bug/1823294 Another Midonet gate failure caused by https://review.openstack.org/#/c/648522/ Proposed fix: https://review.openstack.org/#/c/650599/ * neutron-fullstack fails on stable/rocky at ovs compilation - https://bugs.launchpad.net/neutron/+bug/1823155 Latest Xenial kernels break OVS compilation for fullstack tests Fixed with newer OVS snapshot: https://review.openstack.org/#/c/650022/ High: * Neutron-keepalived-state-change fails to check initial router state - https://bugs.launchpad.net/neutron/+bug/1823038 New functional failure as a result of bug #1818614 Fixed with: https://review.openstack.org/#/c/649991/ backports in progress * Specify FROM clause to join from in test_floatingip_via_router_interface_returns_201 - https://bugs.launchpad.net/neutron/+bug/1823059 Blocking upper-constraints update Fix merged: https://review.openstack.org/#/c/649681 Medium: * Bulk IPv6 subnet create error - https://bugs.launchpad.net/neutron/+bug/1822582 "RuntimeError: Method <function update_port at 0x7fde0e9280c8> cannot be called within a transaction." Has a reproducer * neutron-keepalived-state-change doesnt reap zombies if rootwrap-daemon is used - https://bugs.launchpad.net/neutron/+bug/1822591 Reproduced on current, and need additional eyes/opinion here: were there sudo zombies appearing before? (when the child process gets killed) Low: * [VPNaaS]: Skip check process status for HA backup routers - https://bugs.launchpad.net/neutron/+bug/1822921 In progress * create of segment range for vlan network type fails with error 500 - https://bugs.launchpad.net/neutron/+bug/1823297 Proposed fix: https://review.openstack.org/650245 * ha router sometime goes in standby mode in all controllers - https://bugs.launchpad.net/neutron/+bug/1823314 Rare race condition when creating HA routers, in progress Invalid: * "delete l7 rule" Parameter Passing Error - https://bugs.launchpad.net/bugs/1822960 * "lbaas delete l7 rule & policy" could leave dirty data - https://bugs.launchpad.net/bugs/1822968 2 neutron-lbaas bugs filled, I pointed author to storyboard * Error in os_kenbgp import in tests - https://bugs.launchpad.net/neutron/+bug/1822649 To move to storyboard Probably caused in mass rename, one filename does not match the module name in imports Proposed fix: https://review.openstack.org/#/c/649140/ Incomplete: * legacy router namespaces absence or error run exec - https://bugs.launchpad.net/neutron/+bug/1823023 ip netns commands failing on an OSA deployment, out of scope for neutron for now Regards, -- Bernard Cafarelli

1 0

Call For Proposals: KVM Forum 2019 (30-Oct to 01-Nov – Lyon, France)
by Kashyap Chamarthy 08 Apr '19

08 Apr '19

================================================================ KVM Forum 2019: Call For Participation October 30-November 1, 2019 - Lyon Convention Center - Lyon, France (All submissions must be received before June 15, 2019 at 23:59 PST) ================================================================= KVM Forum is an annual event that presents a rare opportunity for developers and users to meet, discuss the state of Linux virtualization technology, and plan for the challenges ahead. We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2019. At this highly technical conference, developers driving innovation in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can meet users who depend on KVM as part of their offerings, or to power their data centers and clouds. KVM Forum will include sessions on the state of the KVM virtualization stack, planning for the future, and many opportunities for attendees to collaborate. As we celebrate ten years of KVM development in the Linux kernel, KVM continues to be a critical part of the FOSS cloud infrastructure. This year, KVM Forum is joining Open Source Summit in Lyon, France. Selected talks from KVM Forum will be presented on Wednesday October 30 to the full audience of the Open Source Summit. Also, attendees of KVM Forum will have access to all of the talks from Open Source Summit on Wednesday. https://events.linuxfoundation.org/events/kvm-forum-2019/program/call-for-p… Suggested topics: * Scaling, latency optimizations, performance tuning, real-time guests * Hardening and security * New features * Testing KVM and the Linux kernel: * Nested virtualization * Resource management (CPU, I/O, memory) and scheduling * VFIO: IOMMU, SR-IOV, virtual GPU, etc. * Networking: Open vSwitch, XDP, etc. * virtio and vhost * Architecture ports and new processor features QEMU: * Management interfaces: QOM and QMP * New devices, new boards, new architectures * Graphics, desktop virtualization and virtual GPU * New storage features * High availability, live migration and fault tolerance * Emulation and TCG * Firmware: ACPI, UEFI, coreboot, U-Boot, etc. Management and infrastructure * Managing KVM: Libvirt, OpenStack, oVirt, etc. * Storage: Ceph, Gluster, SPDK, etc. * Network Function Virtualization: DPDK, OPNFV, OVN, etc. * Provisioning ======================== SUBMITTING YOUR PROPOSAL ======================== Abstracts due: June 15, 2019 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Submit your proposal here: https://events.linuxfoundation.org/events/kvm-forum-2019/program/call-for-p… Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by August 12, 2019. Speakers will receive a complimentary pass for the event. In case your submission has multiple presenters, only the primary speaker for a proposal will receive a complimentary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, focus on work that needs to be done, difficulties that haven't yet been solved, and on decisions that other developers should be aware of. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2019_BOF Let people you think who might be interested know about your BOF, and encourage them to add their names to the wiki page as well. Please add your ideas to the list before KVM Forum starts. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your the abstract. We will request full biographies if a panel is accepted. ============== HOTEL / TRAVEL ============== This year's event will take place at the Lyon Conference Center. For information on hotels close to the conference, please visit https://events.linuxfoundation.org/events/kvm-forum-2019/attend/venue-trave…. Information on conference hotel blocks will be available later in Spring 2019. ================= DATES TO REMEMBER ================= Submission deadline: Saturday, June 15 at 23:59 PST Notification: Monday, August 12 Schedule announced: Friday, August 16 Slides due date: Wednesday, October 23 Event dates: Wednesday, October 30 - Friday, November 1 Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2019 in October! For questions and comments, please contact the KVM Forum 2019 Program Committee at: kvm-forum-2019-pc(a)redhat.com -- /kashyap

1 0

[TC] PTG Lunch Talks
by Kendall Nelson 08 Apr '19

08 Apr '19

Hello! I think you all have already started to discuss this, but if you haven't, here's the lowdown: You can have 15 min or 30 min on Thursday (we will also have lightning talks from the othe projects attending the PTG after you complete your time) and basically however much time you want on Saturday during lunch (keeping in mind that a lot of people are planning to leave Friday night). Friday is going to be the feedback session so there's not time available lunch that day. tldr; Do you want 15min or 30 min on Thursday? :) -Kendall Nelson

5 6