Posted	Nick	Remark
#openstack-nova - 2019-11-20
22:16:44	sean-k-mooney	dansmith: you primary concern is we loose the key used to encyrpt the os drive and loose data right if we loos the vtpm
22:16:52	sean-k-mooney	wyoud ^ not solve that issue
22:17:10	sean-k-mooney	*would
22:18:37	efried	resize does a destroy and then a spawn?
22:19:02	sean-k-mooney	it will redefine the domain but you dont loose data
22:19:11	sean-k-mooney	and it may change host
22:20:03	sean-k-mooney	e.g. if you resize form a flavor with 10G root disk to one with 20 it will grow the disk file
22:20:17	sean-k-mooney	and if its libvirt the partion table and filesystem if it can
22:20:52	sean-k-mooney	so we would have to copy the vtpm file if we move host
22:21:06	efried	yeah, I'm exploring corner cases with the vTPM. If your resize adds/removes a vTPM where it was previously absent/present, that's fine. If both old & new flavor have the same version/model, we should carry the data. If they have a different version/model...?
22:21:07	sean-k-mooney	if its to the same host we shoudl not need to do anything
22:21:39	sean-k-mooney	if they are different models i would expect you to loose the contents of the tpm
22:21:52	sean-k-mooney	unless we block that intentionally
22:22:08	efried	yes to the first, the second is the question.
22:22:25	efried	there's no way to persist the data, period. The versions/models are incompatible.
22:23:04	sean-k-mooney	ya that is proably true or at least involved to do so i would not try in v1 of this
22:23:31	sean-k-mooney	there might be a way to convert but im not aware of one off the top of my head
22:24:12	efried	sean-k-mooney: not without introspecting, which ain't my business.
22:24:30	sean-k-mooney	swtpm might have a fucntion to do it
22:24:49	sean-k-mooney	but ya unless libvirt support it i think its out of scope
22:24:55	efried	so I'm gonna say don't block it, cause who am I to say you didn't mean to do it
22:25:29	sean-k-mooney	that would be my feeling too
22:25:51	sean-k-mooney	we shoudl documetn it i guess
22:26:02	efried	doing that now
22:26:21	sean-k-mooney	but i dont think we shoudl guard in code against all pebcak errors
22:26:29	efried	agreed
22:27:29	efried	hmph, the thing about saving the swift ID in instance sysmeta has a problem code flow-wise.
22:27:48	efried	because the driver is the thing that knows the vdev is in this particular file path
22:27:59	efried	but the only thing we've asked the driver to do is snapshot.
22:28:19	efried	and (I think) the driver can't tell if it's being asked to snapshot as part of a shelve or backup or...
22:28:47	sean-k-mooney	am im not 100% sure about that last part
22:29:04	efried	so I guess it could edit the sysmeta itself... but if it's not a shelve and the compute mgr is about to blow away the instance, the compute mgr needs a way to get that information so it can stuff it into the image meta.
22:29:13	efried	I guess it can pull it from the instance
22:29:43	efried	so the contract with the virt driver's snapshot method has to spell out where & how this info is stored in the sysmeta.
22:30:29	sean-k-mooney	we create snapshot for shelve but i dont think the compute magener actully calls snapshot as part of that flow i think its donw by the driver
22:30:47	efried	eh?
22:30:49	sean-k-mooney	that said i could be way off base there so im checking
22:30:56	efried	compute manager's shelve calls driver's snapshot
22:31:24	sean-k-mooney	oh ok
22:31:31	efried	https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L5911
22:32:32	sean-k-mooney	ya your right i though we had a shelve fucntion on the driver interface that we called but this is handeled in the compute manager instead
22:33:30	sean-k-mooney	so snapshot is passed the instace so it can get the flavor and image metadata
22:33:58	sean-k-mooney	so the snapshot function can check if the isntace has a vtpm and directly update the system metadata as you said
22:34:14	sean-k-mooney	oh right but it would not know if its a shleve or not
22:36:00	sean-k-mooney	oh it can jsut check the instance.task_state right?
22:36:38	efried	could, but compute mgr has to be able to peel it out anyway, so it's simpler if snapshot just always behaves the same and compute mgr pulls the info out of the sysmeta if it needs it.
22:37:14	sean-k-mooney	ok
22:37:53	sean-k-mooney	anyway night all o/
22:46:34	openstackgerrit	John Garbutt proposed openstack/nova master: WIP: Integrating with unified limits https://review.opendev.org/615180
23:09:16	openstackgerrit	John Garbutt proposed openstack/nova master: Better policy unit tests https://review.opendev.org/657697
23:17:55	efried	argh, destroy_disks=True is no longer sufficient grounds to delete the barbican key :(
23:18:28	efried	In fact, I'm not sure we can "ever" do that.
23:51:05	openstackgerrit	Eric Fried proposed openstack/nova-specs master: Spec: Ussuri: Encrypted Emulated Virtual TPM https://review.opendev.org/686804
23:51:38	efried	phew. dansmith sean-k-mooney TxGirlGeek ^
23:51:45	efried	and jroll
#openstack-nova - 2019-11-21
00:06:38	openstackgerrit	Dustin Cowles proposed openstack/nova-specs master: Update provider config spec for identification conflicts https://review.opendev.org/693414
00:42:50	openstackgerrit	Merged openstack/nova stable/train: Don't delete compute node, when deleting service other than nova-compute https://review.opendev.org/695145
01:11:11	openstackgerrit	Matt Riedemann proposed openstack/nova master: Handle target host cross-cell cold migration in conductor https://review.opendev.org/642591
01:11:12	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add zones wrinkle to TestMultiCellMigrate https://review.opendev.org/643450
01:11:12	openstackgerrit	Matt Riedemann proposed openstack/nova master: Validate image/create during cross-cell resize functional testing https://review.opendev.org/642592
01:11:13	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add negative test for prep_snapshot_based_resize_at_source failing https://review.opendev.org/669013
01:11:13	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add negative test for cross-cell finish_resize failing https://review.opendev.org/643451
01:11:14	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add ConfirmResizeTask https://review.opendev.org/637070
01:11:14	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add confirm_snapshot_based_resize_at_source compute method https://review.opendev.org/637058
01:11:15	openstackgerrit	Matt Riedemann proposed openstack/nova master: Confirm cross-cell resize from the API https://review.opendev.org/637316
01:11:15	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add confirm_snapshot_based_resize conductor RPC method https://review.opendev.org/637075
01:11:16	openstackgerrit	Matt Riedemann proposed openstack/nova master: Deal with cross-cell resize in _remove_deleted_instances_allocations https://review.opendev.org/639453
01:11:16	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add revert_snapshot_based_resize_at_dest compute method https://review.opendev.org/637630
01:11:17	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add RevertResizeTask https://review.opendev.org/638046
01:11:17	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add finish_revert_snapshot_based_resize_at_source compute method https://review.opendev.org/637647
01:11:18	openstackgerrit	Matt Riedemann proposed openstack/nova master: Revert cross-cell resize from the API https://review.opendev.org/638048
01:11:18	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add revert_snapshot_based_resize conductor RPC method https://review.opendev.org/638047
01:11:19	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add archive_deleted_rows wrinkle to cross-cell functional test https://review.opendev.org/651650
01:11:19	openstackgerrit	Matt Riedemann proposed openstack/nova master: Confirm cross-cell resize while deleting a server https://review.opendev.org/638268
01:11:20	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add CrossCellWeigher https://review.opendev.org/614353
01:16:35	gmann	efried: any idea or have you seen 'openstack:' as resource provider name in https://zuul.opendev.org/t/openstack/build/b26bd7fc82d94d4cac97b5481623b629/log/logs/grenade.sh.txt.gz#30397
01:16:55	gmann	this is grenade job on octavia which is failing due to that when moving to py3.
05:23:13	openstackgerrit	Merged openstack/nova stable/pike: Only nil az during shelve offload https://review.opendev.org/693839
06:36:10	openstackgerrit	OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/694717
08:10:09	bauzas	good morning Nova
08:16:32	gibi	bauzas: good morning
08:16:51	bauzas	:)
08:50:26	openstackgerrit	ya.wang proposed openstack/nova master: Handle instance crash event in libvirt driver https://review.opendev.org/695369
09:25:39	openstackgerrit	Stephen Finucane proposed openstack/nova master: docs: Rewrite quotas documentation https://review.opendev.org/667165
09:26:36	stephenfin	bauzas: Morning. Any chance you could look at one or two of the "die, nova-network, die" patches I have up today? Like, say, this really easy one https://review.opendev.org/#/c/684345/ ?
09:26:47	bauzas	lol ok
09:28:32	openstackgerrit	Tushar Patil proposed openstack/nova-specs master: Allow compute nodes to use DISK_GB from shared storage RP https://review.opendev.org/650188
09:34:15	openstackgerrit	Stephen Finucane proposed openstack/nova master: zuul: Remove unnecessary 'USE_PYTHON3' https://review.opendev.org/695380
09:45:22	openstackgerrit	Sylvain Bauza proposed openstack/nova stable/stein: Don't delete compute node, when deleting service other than nova-compute https://review.opendev.org/695381
09:49:08	openstackgerrit	Sylvain Bauza proposed openstack/nova stable/rocky: Don't delete compute node, when deleting service other than nova-compute https://review.opendev.org/695382
09:51:44	openstackgerrit	Sylvain Bauza proposed openstack/nova stable/queens: Don't delete compute node, when deleting service other than nova-compute https://review.opendev.org/695383
10:32:34	yaawang	mdbooth: Hello, can you review the spec again, I'd updated it :) https://review.opendev.org/#/c/693655/
10:52:05	kashyap	yaawang: Hi, on the "no_performance_impact" name -- I still find it too broad and sweeping
10:52:15	kashyap	yaawang: Thanks for addressing my feedback, though!
10:53:14	kashyap	I agree, we don't want to expose "hypervisor"-specific features. (BTW, we are abusing the term "hyerpvisor" here to include QEMU; the term normally includes KVM/Kernel area only.)
10:53:22	kashyap	Maybe "no_migration_perf_impact"
10:57:01	kashyap	But just plain "no_performance_impact" is just _awful_ name (Cc: mdbooth.) At least make it: "no_migration_perf_impact"
11:10:15	yaawang	kashyap: Agree, "no_performance_impact" sounds include live-migrate and migrate. How about "no_perf_impact_live_migration"?
11:12:09	kashyap	yaawang: Yeah, I thought of including "live" as well; almost good - but reverse it: "no_live_emigration_perf_impact"
11:12:55	kashyap	Typo: s/emigration/migration/

Earlier   Later