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

[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 14 Apr '19

14 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 13 Apr '19

13 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