Earlier  
Posted Nick Remark
#openstack-nova - 2018-04-05
20:02:50 melwitt yeah and host_name is derived from the display_name during create
20:02:53 mriedem and you can't change that via the REST API
20:03:09 mriedem https://developer.openstack.org/api-ref/compute/#update-server
20:05:08 melwitt yeah, display_name -> hostname thing only happens during create, I don't see it for update
20:05:48 melwitt https://github.com/openstack/nova/blob/master/nova/compute/api.py#L524
20:06:45 openstackgerrit Mathieu Gagné proposed openstack/nova-specs master: Multiple Fixed-IPs support in network information https://review.openstack.org/312626
20:07:37 mriedem if we updated the hostname that would also likely imply a rebuild needed to get it into the guest
20:07:41 melwitt would this be a problem if anything in the exception message (like string substitutions like display_name) has unicode characters in it? https://review.openstack.org/#/c/555812/5/nova/exception.py@108
20:07:42 mriedem or at least a reboot
20:08:04 mriedem melwitt: ah, yes, probably
20:08:16 melwitt yeah. it would take some doing. I think people have asked for it before but not sure what all would be involved
20:09:10 melwitt was thinking about it since you brought up str() on a different review and someone just proposed a queens backport for the __repr__ one
20:09:26 mriedem efried: do you have the ability to sametime tyler blakes?
20:09:31 mriedem *blakeslee
20:09:36 mriedem i see you guys are bff's
20:09:47 efried mriedem: looking...
20:09:55 eandersson I tested evacuate in mitaka and it failed :'(
20:10:05 melwitt ruh roh
20:10:21 mriedem eandersson: with an instance that has numa?
20:10:32 eandersson Yea - I created 5 instances on two computes with numa pinning
20:10:40 mriedem did it fail because of numa or because of something else?
20:10:47 efried mriedem: Got him on slack. Whaddayaneed?
20:11:04 mriedem efried: see the comment in https://review.openstack.org/#/c/555812/ about unicode
20:11:18 eandersson and evacuated two of them to the other compute, and the two evacuated now have conflicting numa pinning
20:11:32 mriedem eandersson: did you evacuate them at the same time?
20:11:35 eandersson Yes
20:11:38 mriedem well,
20:11:44 mriedem that's your problem :)
20:11:46 efried mriedem: Ack. But... I thought they fixed that issue down at the oslo.log level.
20:11:59 eandersson So the two vms are not conflicting with each other
20:12:08 mriedem eandersson: the numa resource claim happens on the compute service, not in the scheduler, so you're racing with concurrent evac requests to claim the same thing
20:12:09 eandersson they both kept their pinnings
20:12:19 efried mriedem: Hum, that totally wouldn't help here, huh?
20:12:26 mriedem efried: no
20:12:31 eandersson they are conflicting with vms that already were on the compute
20:12:44 mriedem eandersson: hmm
20:12:59 mriedem eandersson: the evac should fail then shouldn't it?
20:13:04 mriedem if the resources are already taken by other VMs on that host
20:13:21 eandersson Yea - I just don't think it knows that it is conflicting
20:13:38 eandersson because it's technically not "invalid" to pin two vms on the same cores
20:14:15 mriedem what is valid or not with the numa stuff at this level is over my head, and would require the likes of cfriesen_, stephenfin, jaypipes, et al
20:14:31 eandersson Yea - hoenstly I bet this is fixed in newer versions
20:14:36 eandersson We just need to upgrade
20:14:53 mriedem hopefully you're not too heavily forked
20:14:59 eandersson nah - it's more cells etc
20:15:14 mriedem upgrading to cells v2 never hurt *anybody*
20:15:18 eandersson it's a big jump, or feels like one at least :D
20:15:37 melwitt yeah. no one has ever complained about it
20:15:55 eandersson How does nova perform now with... a lot of computes?
20:15:57 mriedem if you haven't read up yet, https://docs.openstack.org/nova/latest/user/cells.html - https://docs.openstack.org/nova/latest/user/cellsv2-layout.html -
20:16:24 mriedem there are some summit videos here if you don't like reading https://docs.openstack.org/nova/latest/user/cells.html#cells-v2
20:16:27 mriedem to prime that pump
20:17:10 mriedem well, depends - placement is more meant to solve the lots of computes issue
20:17:31 mriedem doing filtering in sql queries rather than post-db query python filters in memory
20:17:53 mriedem and doing resource claims in the scheduler rather than racing to claim in the computes, hitting conflicts and rescheduling
20:18:08 mriedem you'll need to be at least at pike to do claims via placement in the scheduler
20:18:24 mriedem and pike for mult-cell
20:18:39 melwitt that reminds me, I was looking at this yesterday. need to check on something in the scheduler https://bugs.launchpad.net/nova/+bug/1737465
20:18:39 openstack Launchpad bug 1737465 in OpenStack Compute (nova) "[cellv2] the performance issue of cellv2 when creating 500 instances concurrently" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)
20:18:54 melwitt that's not about a lot of computes, sorry. that's about a lot of instances
20:22:23 eandersson nice
20:22:30 eandersson we are looking at pike at the moment
20:27:43 owalsh melwitt: nope, donno if https://bugs.launchpad.net/nova/+bug/1717915 got resolved. I'd assume it's an oslo.messaging bug
20:27:43 openstack Launchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [Undecided,New]
20:28:04 melwitt owalsh: ack, thanks
20:29:23 owalsh melwitt: actually, I had problems with oslo.messaging the other day where the transport_url handling wasn't right up when some, but not all, of the legacy conf options were set
20:29:54 owalsh not had time to look into it though
20:30:00 efried mriedem, melwitt: tblakes has acked internally and will get on that fup.
20:30:36 melwitt owalsh: by transport_url handling do you mean trying to use both the transport_url config option and the legacy options at the same time? or using only legacy options the resultant transport_url was wrong?
20:31:13 owalsh melwitt: using both transport_url and the legacy options at the same time
20:31:34 owalsh melwitt: I'll mention it on the LP at least
20:31:57 melwitt owalsh: yeah, I'm pretty sure that won't work because one (transport_url) is a superset of the others. like, if transport_url is set, that will be taken and nothing else considered. I'm not 100% sure though
20:32:24 melwitt if it tries to merge them or not
20:32:26 mriedem efried: ok, i hope the requisite amount of gifs were posted on slack during that conversation
20:32:47 efried mriedem: No giphys were harmed in the making of this conversation.
20:32:50 zigo kashyap: Just sent my reply.
20:33:41 owalsh melwitt: that's what I expected, but no. transport_url was correct but nova couldn't connect to rabbitmq. IIRC the legacy conf option for the port was also set but the host options was not
20:34:21 melwitt owalsh: ugh, okay. link me to the LP and I can look later
20:48:58 openstackgerrit Tyler Blakeslee proposed openstack/nova master: Use six.text_type instead of str in NovaException __repr__ https://review.openstack.org/559169
21:00:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Wait for network-vif-plugged before starting live migration https://review.openstack.org/558001
21:00:00 openstackgerrit Matt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available https://review.openstack.org/523548
21:00:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Add "bind_ports_to_host" neutron API method https://review.openstack.org/523604
21:00:01 openstackgerrit Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170
21:00:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method https://review.openstack.org/555947
21:00:02 openstackgerrit Matt Riedemann proposed openstack/nova master: Delete port bindings in setup_networks_on_host if teardown=True https://review.openstack.org/556333
21:00:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron https://review.openstack.org/556334
21:00:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423
21:00:04 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370
21:00:04 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: compute: use port binding extended API during live migration https://review.openstack.org/551371
21:00:05 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Port binding based on events during live migration https://review.openstack.org/434870
21:00:05 openstackgerrit Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537
21:03:16 melwitt owalsh: thanks. I misunderstood you earlier, I thought there was a second LP bug you had opened about the other issue
21:03:36 openstackgerrit Merged openstack/nova master: Make generation optional in ProviderTree https://review.openstack.org/539324
21:04:12 openstackgerrit Tyler Blakeslee proposed openstack/nova master: Use six.text_type instead of str in NovaException __repr__ https://review.openstack.org/559169
21:04:25 owalsh melwitt: ah, yea, not had time to investigate it yet...
21:04:55 melwitt yeah, no worries. just explaining why I said, "link me the LP" because I thought there was a second LP :)
21:05:00 openstackgerrit Matt Riedemann proposed openstack/nova master: DNM: test live_migration_wait_for_vif_plug=True https://review.openstack.org/558006
21:05:39 melwitt you were probably like, "what ... link the same bug you told me about?"
21:06:04 melwitt haha
21:17:35 arvindn05 i am having issues running tox -epep8. Was working fine unti it wasnt...

Earlier   Later