Posted	Nick	Remark
#openstack-nova - 2018-12-18
15:33:49	gibi	mriedem: the order you would like to see would lead to impossible long patch series that cannot be tested on functional or higher level until the last patch that allows booting a server is merged
15:34:20	gibi	e.g. I cannot test any move without booting a server first
15:34:56	gibi	mriedem: I saw the tempest test question, thanks for it. We have the plan to make integration testing, but you had a good point adding that to tempest-full
15:35:42	gibi	mriedem: I did not push for the placement spec too hard because I was time constrained and I knew that the implementation would be blocked this cycle anyhow
15:35:51	mriedem	we have alternatives to tempest-full / integrated gate, but that would need to be thought through
15:36:09	mriedem	i.e. we could pick up the neutron tempest plugin in our nova-next job?
15:36:19	mriedem	but we'd likely be running a bunch of neutron-only tests which we don't want
15:36:29	mriedem	we could maybe whitelist what we want to run though...
15:36:51	mriedem	with the state of the gate lately, i'm not sure how keen i am on introducing more exotic networking tests to the integrated gate
15:36:59	gibi	I think adding the bandwidth related scenarion tests to tempest proper is the way forward as that covers a bunch of nova, neutron and placemetn code as well
15:37:08	mriedem	yeah agree
15:37:25	gibi	and the integrated gate needs to be fixed anyhow :/
15:37:26	mriedem	keep the edge case stuff in the tempest plugin
15:37:33	mriedem	and the happy path stuff in tempest
15:37:37	gibi	I agree
15:38:25	mriedem	and yeah i know about the bottom up approach for a long series of changes, we had that with volume multiattach
15:39:38	gibi	mriedem: I think we are in a bit better situation with bandiwdth as I believ we can use the neutron api extension as a feature flag. We can make the api extension experimental why we progress in nova
15:39:55	gibi	s/why/while
15:42:06	gibi	mriedem: I'm ready to push the last batch of fixes for the first patch you reviewd yesterday. It includes splitting that patch into three. Do you have any comments in flight for the series that you would like to publish before I push?
15:42:26	mriedem	no my comments are posted
15:42:43	gibi	mriedem: OK
15:49:52	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Extend RequestGroup object for mapping https://review.openstack.org/619527
15:49:52	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Transfer port.resource_request to the scheduler https://review.openstack.org/567268
15:49:53	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Fill the RequestGroup mapping during schedule https://review.openstack.org/619528
15:49:53	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239
15:49:54	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Recalculate request group - RP mapping during re-schedule https://review.openstack.org/619529
15:49:54	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Pass resource provider mapping to neutronv2 api https://review.openstack.org/616240
15:49:55	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
15:49:55	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459
15:49:56	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Reject networks with QoS policy https://review.openstack.org/570079
15:49:56	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Reject interface attach with QoS aware port https://review.openstack.org/570078
15:49:57	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Refactor PortResourceRequestBasedSchedulingTestBase https://review.openstack.org/624080
15:49:57	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
15:49:58	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311
15:49:58	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
15:49:59	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Create RequestGroup from neutron port https://review.openstack.org/625941
15:49:59	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
15:50:00	openstackgerrit	Balazs Gibizer proposed openstack/nova master: Include requested_resources to allocation candidate query https://review.openstack.org/625942
15:52:34	openstackgerrit	Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
15:54:22	jackding	hi mriedem: could you revisit https://review.openstack.org/#/c/616692/ and https://review.openstack.org/#/c/603844/ when you got a chance?
16:00:35	mriedem	i'll put them in my browser tab queue but i can't promise anything, lots to get done this week before i'm out next week
16:05:02	openstackgerrit	Merged openstack/nova master: Migrate "reboot an instance" user guide docs https://review.openstack.org/612730
16:12:51	jackding	mriedem: ok, thanks
16:14:12	openstackgerrit	Matt Riedemann proposed openstack/nova master: Remove legacy request spec compat code from API https://review.openstack.org/614309
16:14:13	openstackgerrit	Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat from conductor unshelve_instance https://review.openstack.org/625706
16:14:13	openstackgerrit	Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat code from live migrate task https://review.openstack.org/625705
16:14:14	openstackgerrit	Matt Riedemann proposed openstack/nova master: WIP: Pass request_spec from compute to cell conductor on reschedule https://review.openstack.org/582417
16:14:14	openstackgerrit	Matt Riedemann proposed openstack/nova master: Remove legacy RequestSpec compat from conductor rebuild_instance https://review.openstack.org/625707
16:15:17	openstackgerrit	Merged openstack/nova master: allow tcp-based consoles in get_console_output https://review.openstack.org/624974
16:24:13	openstackgerrit	Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646
16:34:46	openstackgerrit	Krzysztof Opasiak proposed openstack/nova master: Fix server IPs with non-unique network names https://review.openstack.org/625371
17:03:56	openstackgerrit	Jack Ding proposed openstack/nova master: Preserve UEFI NVRAM variable store https://review.openstack.org/621646
17:36:52	melwitt
17:47:29	mriedem	i'd like to beg for some specs reviews on https://review.openstack.org/#/c/393930/ (+2 from dan) and https://review.openstack.org/#/c/612531/ (bunch of +1s but no specs cores yet)
17:47:52	mriedem	former is pretty straight-forward: expose device tags in GET requests
17:47:59	mriedem	latter has a question about a config option
17:50:12	sean-k-mooney	well i cant +2 them but ill try and review them later today.
17:51:34	sean-k-mooney	reading the problem statement of both the seam reasonably useful so ill proably like them :)
17:51:48	mriedem	you can harass your local specs core for me
17:54:45	sean-k-mooney	the serial number one is behavior i was completely un aware of until now
19:03:47	canori01	Hello, is there currently a way to prevent a resize operation to go accross availability zones? I have the availabilityzone filter enabled, but it occasionally tries to go to other AZ's
19:19:50	mriedem	canori01: if the server is created without specifying an AZ and https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_schedule_zone is not set then nova doesn't restrict the server to a single AZ
19:19:57	mriedem	which is probably why you're seeing them move sometimes
19:21:08	mriedem	which reminds me https://review.openstack.org/#/c/567701/
19:30:48	sean-k-mooney	hehe ill add that to my review list after https://review.openstack.org/#/c/594527/
19:33:52	openstackgerrit	Lee Yarwood proposed openstack/nova master: WIP block_device: Optionally recreate attachments when refreshing connection_info https://review.openstack.org/579004
19:35:08	sean-k-mooney	melwitt: johnthetubaguy jaypipes if ye have time could you take a look at https://review.openstack.org/#/c/591607/11
19:43:01	lyarwood	melwitt / mriedem_afk ; https://review.openstack.org/#/c/618478/ - Would you mind hitting this dead horse again, preferably enough times to kill it if it's a non-starter so I can move on and try fixing this another way, cheers!
19:44:15	melwitt	sean-k-mooney: will do
19:44:32	melwitt	lyarwood: yes, sorry I didn't get to it yesterday. will do it today
19:44:48	lyarwood	hmm killing a dead horse, I think it's time to log off for the day.
19:44:56	lyarwood	melwitt: ack np thanks again
19:51:26	openstackgerrit	Merged openstack/nova master: Drop request spec migration code https://review.openstack.org/614265
20:06:59	canori01	If I set an invalid default_schedule_zone, will that prevent the instances from crossing AZ's?
20:50:07	mriedem_afk	canori01: it would likely prevent the instance from even booting
20:51:40	canori01	mriedem: The problem I have is I have different storage backends for the boot volume on my different az's. I want the instances to boot in any az, but not move cross-AZ after booting. Is that possible?
20:54:06	mriedem	do you want the server to be in the same AZ as the root volume? and if so, do the root volumes have non-default AZs?
20:54:14	mriedem	i.e. specific cinder AZs per storage type/backend?
20:54:51	mriedem	if so, you might be interested in https://review.openstack.org/#/c/469675/
20:55:09	mriedem	otherwise i'm not aware of a way to restrict a server to an AZ after it's been created and the user didn't request it
20:55:17	mriedem	jaypipes: are you? ^
20:56:07	canori01	The boot volumes are all ephemeral actually. I just want the instance to stay in the az of the hypervisor it orginally spawned in
20:56:10	mriedem	you can restrict a server to certain AZs implicitly by pinning the flavor/images to host aggregates
20:56:47	canori01	ah, alright. I think I'll have to go the flavor route
20:56:56	mriedem	because otherwise you have latency between the server and the root volume, thus defeating the HPC gains you had by co-locating them on the same host, yes?
20:58:10	mriedem	with https://review.openstack.org/#/c/469675/ if you set [cinder]cross_az_attach=False and the user doesn't request an AZ, the compute API would proxy the AZ from the root volume to the server so they are co-located in the same AZ (assuming the cinder volume has a non-default AZ)
20:58:37	mriedem	i'm not sure that helps you unless you have an AZ *per host*
20:59:23	mriedem	canori01: http://lists.openstack.org/pipermail/openstack-dev/2017-February/thread.html#112847 is also related
21:13:42	canori01	mriedem: Thanks!
21:15:10	mriedem	canori01: yw
22:12:58	openstackgerrit	Jack Ding proposed openstack/nova-specs master: Flavor Extra Spec and Image Properties Validation https://review.openstack.org/618542
22:30:14	jackding	cfriesen: regarding https://review.openstack.org/#/c/620959, it would be nice to fail earlier at compute node startup, so iterate through list of cpu models and validate each cpu_model + cpu flags using host.compare_cpu()?
22:31:20	cfriesen	jackding: I think that would be better than waiting for it to fail with no end-user feedback later on when someone tries to use it.
22:32:03	jackding	cfriesen: make sense, I will modify the spec.
23:03:01	openstackgerrit	Jack Ding proposed openstack/nova-specs master: Select cpu model from a list of cpu models https://review.openstack.org/620959
23:04:23	jackding	cfriesen: new patchset uploaded
23:07:45	openstackgerrit	Jack Ding proposed openstack/nova-specs master: Flavor Extra Spec and Image Properties Validation https://review.openstack.org/618542
23:09:31	jackding	jaypipes: could you revisit https://review.openstack.org/#/c/618542/ see if your questions are answered? Thanks,
23:28:36	jackding	cfriesen: You mean host.compute_cpu() is only for libvirt driver or do you mean the entire spec only applies to libvirt driver?
#openstack-nova - 2018-12-19
00:19:28	openstackgerrit	Hongbin Lu proposed openstack/nova-specs master: [WIP] Support scheduling VM's NICs to different PFs https://review.openstack.org/626055

Earlier   Later