Earlier  
Posted Nick Remark
#openstack-nova - 2017-12-01
14:55:35 mriedem if those instances were in a server group policy, we are likely destroying those
14:57:32 giblet without the late check we break the group policy, with the late check even nova doesn't reschedule we at least fail the evac instead of breaking the policy
14:57:43 giblet that is already better
14:58:05 giblet of course it would be nice to reschedule
14:59:32 mriedem https://bugs.launchpad.net/mos/+bug/1735407/comments/3
14:59:34 openstack Launchpad bug 1735407 in Mirantis OpenStack 9.x "[Nova] Evacuation doesn't respect anti-affinity rules" [High,New] - Assigned to Oleksiy Molchanov (omolchanov)
14:59:37 mriedem my analysis
14:59:50 mriedem i don't really want to add a reschedule loop for evacuate
15:00:20 mriedem long-term we model affinity in placement and use that, but i'm not entirely sure that will fix this case either
15:00:31 leakypipes mriedem: ++
15:00:48 giblet mriedem: +1 for your analysis
15:01:01 giblet mriedem: can we just add the post check without reschedule?
15:02:01 mriedem well i guess the affinity stuff in placement would mean we somehow 'claim' that the instance we're scheduling / evacuating is going to be on some target host,
15:02:10 mriedem so a concurrent request gets that information when asking placement where it should go
15:02:18 mriedem not sure how that is all going to work out
15:02:23 mriedem since we don't want to model server group policies in placement
15:05:30 mriedem giblet: https://bugs.launchpad.net/mos/+bug/1735407/comments/4
15:05:31 openstack Launchpad bug 1735407 in Mirantis OpenStack 9.x "[Nova] Evacuation doesn't respect anti-affinity rules" [High,New] - Assigned to Oleksiy Molchanov (omolchanov)
15:05:49 mriedem giblet: doing the late check might be reasonable
15:05:56 mriedem fail the evacuate, so the user can retry
15:06:55 giblet I vote for option 1) now and maybe consider prioritizing affinity impl with Placement in the future
15:07:52 giblet mriedem: I have to run soon but I have already looked into adding such late check before so I can take this bug if it can wait until Monday
15:08:03 mriedem sure
15:08:25 mriedem assigned to you
15:08:45 giblet cool, thanks
15:09:51 mriedem superdan: here is belmiro's build request cellsv1 bug https://bugs.launchpad.net/nova/+bug/1735353
15:09:52 openstack Launchpad bug 1735353 in OpenStack Compute (nova) "build_request not deleted when using cellsV1 and local nova_api DB" [Undecided,New]
15:16:43 mriedem cdent: figleaf: rest api error code question,
15:16:50 mriedem https://bugs.launchpad.net/nova/+bug/1735329 500 is surely not correct in this case,
15:16:51 openstack Launchpad bug 1735329 in OpenStack Compute (nova) "console-log return 500 if n-cpu is shutdown" [Undecided,New] - Assigned to hongbin (hongbin034)
15:16:54 mriedem i'm thinking 409?
15:17:38 cdent s
15:18:38 fried_rice mriedem cdent 503 "Service Unavailable" ?
15:19:09 cdent 503 doesn’t really mean that, we’ve tried to discourage it
15:19:22 mriedem was going to say, i've been told not to use 501, 503, etc
15:19:23 cdent mriedem: I reckon 409 is probably right
15:19:33 mriedem this api already returns 409 so that's a good fit
15:19:58 mriedem hongbin: ^
15:20:08 fried_rice "conflict" seems weird for this, but whatevs.
15:20:11 cdent 503 is more for when a proxy is involved
15:20:12 hongbin o/
15:20:30 cdent fried_rice: conflict is that the state of the resource is not aligned with what you need it to be
15:20:42 fried_rice That's a stretch.
15:20:49 fried_rice IMO
15:20:55 fried_rice But I'm no expert.
15:21:11 cdent that’s what conflict really means
15:21:34 openstackgerrit Dan Smith proposed openstack/nova master: Unmap compute nodes when deleting host mapping https://review.openstack.org/524641
15:21:41 mriedem ooo
15:25:50 mriedem not sure how to find out our default http response timeout
15:26:03 superdan mriedem: ^
15:26:12 mriedem superdan: i know, already -1ed :)
15:26:56 mriedem or is the http response timeout configurable in uwsgi
15:26:58 mriedem ?
15:27:21 superdan mriedem: https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L707
15:27:36 mriedem superdan: that's not what you want
15:27:39 mriedem that's the nodename
15:27:44 mriedem ComputeNode.host is the hostname
15:28:02 mriedem it's totally confusing
15:28:45 superdan um
15:30:08 superdan I thought get_all_by_host was by service hostname
15:30:17 superdan why else would be it a multi-return?
15:30:25 superdan I feel like I've made this mistake like eight times
15:30:59 mriedem let me see what the actual HostMapping.host field is set from
15:31:07 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
15:31:07 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
15:31:08 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
15:31:20 mriedem host_mapping = HostMapping(
15:31:20 mriedem ctxt, host=compute.host,
15:31:20 mriedem cell_mapping=cm)
15:31:30 mriedem in _check_and_create_host_mappings
15:36:52 superdan oh hypervisor_hostnme is actually the node uuid for ironic isn't it
15:36:58 superdan gawd why can't we call things what they are
15:38:06 cdent superdan++
15:41:14 superdan well, regardless, hostmapping uses cn.host
15:41:21 superdan so that's what I want anyway
15:43:44 mriedem superdan: ? so you're going to use get_by_hypervisor?
15:43:54 superdan no I mean the .host field
15:44:02 superdan I really thought .host was the service host
15:44:11 superdan because we have get_by_host_and_node
15:44:48 superdan I'm doing this all whilst on a call, which I really shouldn't do
15:44:49 mriedem what gets passed to delete_host is the computenode.host, so you have to use ComputeNodeList.get_all_by_host, yes?
15:44:52 mriedem ok
15:45:06 mriedem the only time this would return more than 1 node is ironic
15:45:26 openstackgerrit Merged openstack/nova stable/pike: Fix ValueError when loading old pci device record https://review.openstack.org/524157
15:45:35 superdan that's what I mean, what we pass is what is in hostmapping.host, which is populated from computenode.host
15:46:16 superdan which I guess is the service hostname
15:46:55 mriedem yeah, it's what comes from CONF.host
15:47:12 superdan I really didn't think that's what was in hostmapping
15:53:35 openstackgerrit Dan Smith proposed openstack/nova master: Unmap compute nodes when deleting host mapping https://review.openstack.org/524641
15:53:36 superdan mriedem: try that
15:57:14 bauzas superdan: mriedem: yeah, so the compute service hostname is the host, and the Ironic node UUID is the hypervisor_hostname
15:57:54 bauzas so, when we get all the nodes for a host, we should get all the ironic nodes related to the specific nova compute
15:58:07 superdan yeah, that's not really the confusion,
15:58:12 superdan it's what was in hostmapping.host for me,
15:58:18 superdan and I thought it was the node
15:58:25 bauzas ah no, unfortunatel
15:58:28 bauzas indeed
15:59:43 bauzas and yeah, the main reason why we don't modify the field to be "node" instead of "hypervisor_hostname" is because it would be a huge change
15:59:44 mriedem superdan: want to fix the alignment in the test?
16:00:04 mriedem putting comments next to the fields in the code would probably help

Earlier   Later