Posted	Nick	Remark
#openstack-nova - 2019-04-23
15:31:48	aspiers	kashyap: thanks for relaying the message from danpb - indeed hard_limit is no longer proposed in the latest version of the SEV spec http://logs.openstack.org/94/641994/11/check/openstack-tox-docs/a439f50/html/specs/train/approved/amd-sev-libvirt-support.html#memory-locking-and-accounting
15:33:10	kashyap	aspiers: Noted. Thanks for the pointer
15:33:42	kashyap	aspiers: BTW, I must say, this is one of the most well-written specs I've evern seen. Nice work.
15:33:50	aspiers	kashyap: thanks! :)
15:35:00	aspiers	I received a lot of great advice on it over 2 cycles, which has helped hugely
15:35:55	kashyap	Yeah, it shows the careful, unhurried effort to think-through the problem and incorporating the feedback.
15:37:06	aspiers	Well I'm too stubborn to give up, and not quite stupid enough to believe that I could shove a spec down your throats before it was ready and expect to succeed ;-)
15:37:36	openstackgerrit	Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.opendev.org/637955
15:40:35	kashyap	alex_xu: By the way, the CPU_TRAITS_MAPPING takes both AMD _and_ Intel flags, yes?
15:41:28	alex_xu	yes
15:42:04	kashyap	aspiers: Hehe, noted. (Sustained concentration is a "feature" in this distracted world with 280-char attention spans.)
15:42:11	kashyap	alex_xu: Thx.
15:42:14	aspiers	Indeed
15:43:32	artom	Although realistically, that'll probably mean drugs, so maybe not?
15:43:51	kashyap	What a charitable interpretation.
15:43:52	aspiers	LOL
15:44:22	artom	Is it? Charitable, I mean?
15:44:24	aspiers	It's not a coincidence that I'm currently doing a meditation course on productivity ;-)
15:44:37	kashyap	alex_xu: As I add these missing traits to the CPU_TRAITS_MAPPING, I have an uneasy feeling that we're duplicating work
15:44:58	kashyap	alex_xu: I think we're OK with its growth over the years...
15:45:10	kashyap	aspiers: Nice.
15:45:43	alex_xu	kashyap: yes, welcome any better idea
15:46:18	kashyap	alex_xu: Nothing currently :-) Will keep thinking about this problem, will let you know if I come up with anything better
15:46:31	alex_xu	kashyap: cool, thanks
15:50:56	mriedem	adrianc: some comments in https://review.opendev.org/#/c/649345/
15:51:58	mriedem	adrianc: if you agree, i'm willing to make that change and then still +2
15:52:03	mriedem	it's just docs and variable naming
15:58:52	efried	dansmith, mriedem, gibi: Did we ever settle on the accepted way to add resource/trait/aggregate things via a request_filter so they end up in the GET /a_c request?
16:00:21	mriedem	not that i know of, i know gibi posted a patch,
16:00:30	mriedem	and my eyes glazed over at the discussion within my multiattach capability trait patch
16:00:51	mriedem	for now i'm just shoving a trait in the flavor extra spec on the request spec before it hits the scheduler and making sure the change isn't persisted
16:00:58	mriedem	i.e. hitching a ride to scheduler town
16:01:09	mriedem	cash, grass, or ...
16:01:17	mriedem	no traits ride for free
16:02:44	efried	making sure the change isn't persisted?
16:03:00	mriedem	RequestSpec.flavor gets persisted
16:03:17	efried	so you're adding it to the flavor extra spec until the GET /a_c and then removing it?
16:03:18	mriedem	i want to make sure that twiddling RequestSpec.flavor.extra_specs for a one-time scheduler run doesn't get persisted
16:03:35	mriedem	nothing is explicitly removing it,
16:03:45	efried	...you just aren't saving it
16:03:45	mriedem	you reset changes on the object so that when it's saved those changes aren't persisted
16:03:49	efried	okay
16:05:14	openstackgerrit	Matt Riedemann proposed openstack/nova-specs master: Delete approved template in move_implemented_specs https://review.opendev.org/592755
16:08:49	jaypipes	mdbooth: what is the primary use case for the volume-update operation? (as opposed to just doing a detach-volume, start-new-instance-elsewhere, attach-volume flow?
16:10:44	mriedem	volume live migration and retypes
16:11:22	mriedem	for a retype it's a new volume, else it's the same volume on a different backend with the same type (i think)
16:11:41	mriedem	https://docs.openstack.org/nova/latest/user/support-matrix.html#operation_swap_volume
16:13:17	jaypipes	mriedem: what's the use case though?
16:13:41	aspiers	jaypipes wins the Review Of The Week award for a perfect use of a Big Lebowski quote
16:13:48	jaypipes	aspiers: yw
16:14:02	mriedem	jaypipes: this feels like a trap
16:14:09	mriedem	what's the use case for live migration?
16:14:17	jaypipes	mriedem: no, I'm honestly curious.
16:14:30	jaypipes	mriedem: is volume live migration different from live migration?
16:14:40	mriedem	yes
16:14:45	mriedem	it's initiated through cinder
16:14:50	mriedem	smcginnis: maybe you want to elaborate here ^
16:15:15	jaypipes	mriedem: so this is not an operation a user would ever issue, right?
16:15:19	mriedem	https://docs.openstack.org/cinder/latest/admin/blockstorage-volume-migration.html
16:15:30	jaypipes	(like instance live migration is not an operation any normal user even knows about)
16:15:42	mriedem	for volume migration i think that is correct, it's admin-only by default,
16:15:48	mriedem	but retype is admin or owner of the volume aka the user
16:15:59	mriedem	https://developer.openstack.org/api-ref/block-storage/v3/?expanded=migrate-a-volume-detail,retype-a-volume-detail#retype-a-volume
16:16:15	mriedem	"Change the volume type of existing volume, Cinder may migrate the volume to proper volume host according to the new volume type."
16:16:27	mriedem	i think of volume retype like server resize
16:16:52	mriedem	by default retyping should not migrate the volume, but the user can override that
16:17:08	mriedem	"If the volume is attached to a server instance and will be migrated, then by default policy only users with the administrative role should attempt the retype operation."
16:17:22	mriedem	^ is because the nova swap volume api is admin-only by default
16:17:25	mriedem	it's f'ing great
16:17:31	jaypipes	hrmph
16:18:03	mriedem	so i as a non-admin user could try to retype my attached volume and migrate it which could then blow up b/c nova rejects my non-admin user token passed by proxy from cinder
16:18:14	aspiers	efried: when you have a moment, if you can give me some newb pointers about how encrypted_memory=true would be implemented, I can submit a new patch set proposing that
16:18:24	mriedem	not sure if cinder has added anything to escalate that token to admin/service user in the last 3 years
16:19:19	mriedem	the more sane thing to do would probably be stop the instance, detach the volume, retype it, re-attach and then restart the server
16:20:14	jaypipes	or design your application to write to multiple volumes in a replica set instead of one giant panda volume.
16:20:21	jaypipes	but I digress.
16:20:28	mriedem	my enterprise panda volume is very important and can never go down
16:20:38	mriedem	it runs my website visit counter
16:20:44	jaypipes	:)
16:20:58	jaypipes	new band name: Enterprise Panda Volume.
16:21:06	jaypipes	or EPV for the cool kids.
16:21:08	mriedem	EPV if you're talking to execs
16:21:11	mriedem	yeah :)
16:21:12	panda	uh ?
16:21:13	jaypipes	:)
16:21:16	mnaser	LOL
16:21:22	jaypipes	hahahaha
16:21:22	aspiers	there is actually a panda on this channel who is gonna be wondering why they suddenly got a bunch of notifications :-D
16:21:24	jaypipes	panda: :)
16:21:36	aspiers	oh, I was too late
16:21:38	panda	can I get back to sleep ?
16:21:43	panda	:)
16:21:47	aspiers	:)
16:21:50	jaypipes	panda: sorry, a "Panda" is a pet virtual machine that can not be killed otherwise it's an international incident :)
16:22:01	jaypipes	sorry for waking you!
16:22:05	panda	oh my.
16:23:11	mriedem	oh it also looks like swap volume will work on root volumes, whereas detach / attach does not (yet)
16:23:37	jaypipes	mriedem: yuck.
16:23:39	jaypipes	:P
16:23:46	panda	nice to know more nice uses of my nick :)

Earlier   Later