| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-05 | |||
| 19:53:09 | eandersson | Yea - makes sense | |
| 19:53:32 | melwitt | they thought "oh I can use this tool to talk to the openstack private cloud" and something custom in the cloud API tripped it up so they couldn't use the tool | |
| 19:54:11 | mriedem | i can't see anything in loadables or filters that used to use extension points | |
| 19:54:23 | mriedem | looks like it's just always been classpath loading since 2012 | |
| 19:54:28 | eandersson | Yea - the first place I always look is setup.cfg | |
| 19:56:52 | melwitt | oh, hm. okay | |
| 19:57:05 | melwitt | I dunno what I was thinking of. maybe I dreamed it | |
| 19:57:19 | mriedem | naw i thought they were loadable via ext point too | |
| 19:57:23 | mriedem | i know the driver is | |
| 19:57:43 | mriedem | and compute rest api extensions used to be loadable via ext point | |
| 19:57:58 | mriedem | i think that was also killed in liberty | |
| 19:58:11 | melwitt | right | |
| 19:58:39 | eandersson | btw more crazy questions... why was a notifaction on instance rename never implemented? | |
| 19:58:58 | mriedem | no one ever asked for/wrote it? | |
| 19:59:09 | eandersson | I see - that simple huh? :D | |
| 19:59:09 | mriedem | there are notifications on instance.update | |
| 19:59:11 | mriedem | which is what a rename is | |
| 19:59:24 | mriedem | https://docs.openstack.org/nova/latest/reference/notifications.html#versioned-notification-samples | |
| 19:59:57 | mriedem | although it's not like create where you have a start/end notification | |
| 20:00:24 | mriedem | oh, well looky here: "old_display_name": null, | |
| 20:00:56 | mriedem | http://git.openstack.org/cgit/openstack/nova/tree/nova/notifications/base.py#n121 | |
| 20:01:00 | mriedem | so yeah, instance.update is what you want | |
| 20:01:15 | eandersson | cool - maybe I can add that to designate | |
| 20:01:29 | eandersson | https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py#L73 | |
| 20:01:56 | mriedem | hmm, i don't think the display_name is what you're looking for | |
| 20:02:20 | mriedem | "host_name": "some-server", | |
| 20:02:30 | mriedem | host_name is what's used for the DNS entry i think | |
| 20:02:35 | eandersson | Yea - it is | |
| 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 | 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: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: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 | openstack | Launchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [Undecided,New] | |
| 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: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 | |