Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-19
09:42:47 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Add policy to InstanceGroup object and api models. https://review.openstack.org/563375
09:42:48 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Add policy field to ServerGroup notification object https://review.openstack.org/563401
09:42:49 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Change the anti-affinity Filter to adapt to new policy https://review.openstack.org/571166
09:42:50 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Adapt _validate_instance_group_policy to new policy model https://review.openstack.org/571465
09:42:51 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Microversion 2.64 - Use new format policy in server group https://review.openstack.org/567534
09:43:34 openstackgerrit jichenjc proposed openstack/nova master: Adjust log style and remove ocata support https://review.openstack.org/576462
09:54:32 openstackgerrit Merged openstack/nova-specs master: Spec: Handling Reshaped Provider Trees https://review.openstack.org/572583
10:30:13 openstackgerrit Merged openstack/nova master: Only run placement request filters when Placement will be called https://review.openstack.org/569969
10:53:01 openstackgerrit Merged openstack/nova master: libvirt: remove unused get_ovs_interfaceid() https://review.openstack.org/572699
11:21:34 vpc_ hi nova guys
11:39:11 efried ō/
12:01:14 openstackgerrit Merged openstack/nova master: Add policy rule to block image-backed servers with 0 root disk flavor https://review.openstack.org/561284
12:22:33 openstackgerrit Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435
12:22:34 openstackgerrit Chris Dent proposed openstack/nova master: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857
13:03:35 mriedem gibi: i answered your questions here https://review.openstack.org/#/c/556334/ - i don't think i have any (obvious to me) changes to make
13:18:08 mriedem sahid: thanks for your reviews on that live migration series of mine, replied in https://review.openstack.org/#/c/515423/ and https://review.openstack.org/#/c/551370/ - it is a bit hairy, i struggled a bit while writing this for what definitely needs to come over from the destination host to build the guest xml
13:19:15 gibi mriedem: here it is binding:host https://review.openstack.org/#/c/523604/18/nova/network/neutronv2/api.py@1223 but here it is binding:host_id https://review.openstack.org/#/c/556334/15/nova/network/neutronv2/api.py@2422 so I'm confused
13:21:32 mriedem gibi: so when we create the port binding, this is checking the host field in the request body https://review.openstack.org/#/c/414251/66/neutron/plugins/ml2/plugin.py@2044
13:21:43 mriedem from neutron-lib, the field names are defined as: https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings_extended.py#L58
13:22:02 mriedem the binding:host_id is the field on the port resource, not the binding resource
13:22:20 mriedem when you set a port binding resource to active, it atomically updates the port's binding:host_id field
13:22:27 mriedem it's confusing that they are different, but that's the way it is
13:22:52 mriedem re: https://review.openstack.org/#/c/523604/18/nova/network/neutronv2/api.py@1223
13:22:59 gibi Ahh I see now. the difference between the spec and the neutron code did not make this easier :)
13:23:12 mriedem yeah as i said in ^ the spec is outdated
13:23:16 gibi yeah
13:23:27 mriedem and the neutron ml2 plugin and port binding extended api reference doesn't yet have api ref docs
13:23:33 mriedem something i asked mlavalle about
13:24:28 mriedem note that if the binding resource field was 'host_id' rather than 'host' the live migration job would be failing at the top of the series
13:25:00 mriedem hmm, which it is now, /me looks
13:25:49 mriedem haven't seen this before http://logs.openstack.org/37/522537/29/check/nova-live-migration/08534a4/logs/screen-n-cpu.txt.gz?level=TRACE#_Jun_19_01_11_49_573713
13:26:37 mriedem this might be something new in libvirt 4.0.0 using the queens UCA
13:26:43 mriedem which we weren't using last time i checked these job results
13:28:38 gibi having a tempest test at the top helps, thanks
13:29:47 gibi mriedem: regarding the rollback of multiple port activations. I don't know what can we do so let's keep it as is and try to fix it later when we see the real problem
13:30:08 gibi mriedem: I will try to get back to your neutron-new-port-binding-api series to re-review but it might not be today
13:30:48 mriedem gibi: sure, that's ok, thanks for what you've done so far
13:37:23 gibi mriedem: btw, Kevin_Zheng fixed up https://review.openstack.org/#/c/564092/ and I'm +2 so you can send it in
13:37:48 mriedem ok
13:40:01 gibi mriedem: I tried to reporduce bug 1777540 but I failed at https://bugs.launchpad.net/nova/+bug/1777157/comments/4
13:40:03 openstack Launchpad bug 1777157 in OpenStack Compute (nova) "cold migration fails for ceph volume instances" [Undecided,New]
13:40:04 openstack bug 1777540 in OpenStack Compute (nova) ""IndexError: list index out of range" in ExceptionPayload.from_exception during resize failure" [Undecided,New] https://launchpad.net/bugs/1777540
13:40:40 gibi mriedem: I don't know how can I hit code https://github.com/openstack/nova/blob/530c24596a74a6115f2e944176c46e4f3d199811/nova/compute/manager.py#L4079
13:40:47 gibi mriedem: from the nova API
13:42:14 gibi mriedem: is short how can I trigger a migrate / resize that targets the same host and does not change the flavor of the instance
13:44:44 mriedem gibi: you could specify the host field when cold migrating?
13:45:00 mriedem https://developer.openstack.org/api-ref/compute/#migrate-server-migrate-action
13:45:29 gibi mriedem: I tried, I got {"badRequest": {"code": 400, "message": "Cannot migrate to the host where the server exists."}}
13:45:46 mriedem hmm, because https://github.com/openstack/nova/blob/530c24596a74a6115f2e944176c46e4f3d199811/nova/compute/api.py#L3366
13:46:14 mriedem which is technically a behavior change since some drivers allow you to migrate to self https://github.com/openstack/nova/blob/530c24596a74a6115f2e944176c46e4f3d199811/nova/compute/manager.py#L4077
13:46:21 mriedem thinking vmware
13:46:59 openstackgerrit Dan Smith proposed openstack/nova stable/queens: [Stable Only] Add amd-ssbd and amd-no-ssb CPU flags https://review.openstack.org/576270
13:46:59 mriedem yeah vmware is the only driver that has supports_migrate_to_same_host=True
13:47:11 mriedem since the compute host is just managing a vcenter cluster of esxi hosts
13:47:50 gibi mriedem: it is added in Queens by https://review.openstack.org/#/c/408955/
13:48:32 mriedem yeah i remember reviewing it :(
13:48:57 gibi mriedem: but the bug report says this issue was visible in queens so I don't get it how
13:49:10 mriedem so they weren't picking a host for the cold migrate,
13:49:15 mriedem maybe they only have 1 compute?
13:49:23 gibi then I get NoValidHost
13:49:38 mriedem or, maybe aggregates are setup in such a way that the same host is picked?
13:50:09 mriedem or you have 2 hosts and the other is full or disabled?
13:50:26 gibi OK, good ideas, let me dig
13:51:04 mriedem gibi: you also have to have allow_resize_to_same_host=True in nova.conf
13:53:37 sahid mriedem: thanks will look at that
13:53:59 gibi mriedem: does allow_resize_to_same_host affects migration?
13:56:31 gibi mriedem: yes, it does
13:56:55 openstackgerrit Dan Smith proposed openstack/nova stable/queens: [Stable Only] Add amd-ssb and amd-no-ssb CPU flags https://review.openstack.org/576270
13:58:27 dansmith kashyap: okay, I'm confused from all your edits to the bug.. going off of the libvirt patch it says it should be amd-ssbd and amd-no-ssb
13:59:47 dansmith I just processed the email notifications from your bug edits and it seems like you dropped the 'b' off the end of the first
13:59:49 dansmith er, the 'd'
14:01:54 openstackgerrit Dan Smith proposed openstack/nova stable/queens: [Stable Only] Add amd-ssbd and amd-no-ssb CPU flags https://review.openstack.org/576270
14:01:56 dansmith whatever, changing it to match the libvirt patch
14:02:04 dansmith changing it *back* I should say
14:03:01 kashyap dansmith: Damn, I was bleary-eyed without coffee in the morning, and mistook Matt's comment
14:03:06 kashyap My bad; let me go update it right away
14:03:07 dansmith the bug also still calls it "amdb-no-ssb" by the way
14:03:15 kashyap Sorry about that.
14:03:19 kashyap Adjusting it
14:04:18 kashyap Originally I typoed only one place, in the summary. But somehow thought I did it all over the description.
14:04:45 dansmith and I copied those two names into the conf file, but then used the libvirt patch as reference for all the text I typed
14:07:06 bauzas efried: good morning
14:07:14 efried bauzas: Howdy!
14:07:37 bauzas efried: about efried: about https://review.openstack.org/#/c/564214/5/nova/tests/unit/virt/libvirt/test_driver.py@19853 the problem is that I need to provide a nova.conf fake file for this
14:07:45 mriedem alex_xu: so should we put https://review.openstack.org/#/c/560317/ in a runway or hold off for now?
14:08:14 bauzas efried: I can't just set the options directly ;)
14:08:31 efried bauzas: whyzat? Because the groups are dynamic?
14:09:07 efried oh, sorry, I was thinking of the wrong patch.
14:09:47 efried bauzas: wait, no I'm not. Can't you set the one opt, then call the dynamic conf thingy, then set the subsequent opt?
14:10:22 kashyap dansmith: Updated the bug. Struggling with too many acronyms. :-)
14:12:41 bauzas efried: well, if I'm providing 2 types but only set one opt, the second opt would get an exception
14:12:59 mriedem cdent: i think i'm going to put the optional placement db series into the available runway slot, are you around to deal with reviews on it for the next 2 weeks (shouldn't really take that long, the big pieces have merged it looks like)
14:13:15 openstackgerrit Merged openstack/os-traits master: Adds HW_CPU_HYPERTHREADING standard trait https://review.openstack.org/576030
14:13:33 cdent a) cool, b) yes, c) there was a big bug in the next in line, but I fixed it, so we good
14:13:45 mriedem ack
14:13:47 cdent I except there will be some documentation concerns, which is good and right
14:13:51 efried bauzas: Sorry, I'm not understanding. Why wouldn't you provide 2 types and set both opts?
14:14:16 bauzas efried: sec
14:14:58 sq4ind Hey guys, have a problem with long running tasks (migrations). I've enabled send_service_user_token and allow_expired but still sometimes it fails. Here are logs: https://pastebin.com/cY82PP34 . Any idea?
14:15:01 sq4ind Thanks

Earlier   Later