Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-11
15:51:58 mriedem i think this is purely a swap volume wrinkle
15:52:21 mriedem so i think i need to handle that in between the libvirt patch and https://review.openstack.org/#/c/531244/
15:52:28 mriedem since https://review.openstack.org/#/c/531244/ bumps the rpc version
15:52:54 stvnoyes mriedem: at this point in Queens, what about explicitly not allowing swap volume if the volume is MA'd? Then we can test swap more exhaustively for rocky...
15:53:47 mriedem stvnoyes: because that means you'd need a new microversion for swap volume with multiattach support in rocky, and that would mean cinder (using nova client) would have to know to send that microversoin if swapping with a MA volume
15:54:04 mriedem stvnoyes: what needs to happen is like a 3 line code change i think
15:54:07 ildikov mriedem: I'm good with your solution
15:54:11 stvnoyes ah ok
15:54:21 mriedem if new_volume['multattach']: new_connection_info['multiattach'] = True
15:54:39 ildikov yep
15:54:41 mriedem thinking about a tempest test scenario to tickle this...
15:55:07 mriedem attach non-multiattach volume A, swap to multiattach volume B, then attach B to a 2nd serer
15:55:08 mriedem *server
15:55:31 mriedem if we didn't fix the swap volume piece, the 2nd attach for B on the 2nd server should be wonky
15:55:36 ildikov mriedem: do we track if the old volume was multiattach, but the new one is not?
15:55:51 mriedem ildikov: no. we can figure that out if needed, but i'm not sure if we care.
15:56:22 mriedem we did say in the cinder spec that you can't retype an in-use volume to change it's multiattach value
15:56:52 ildikov but with swap it's a new volume?
15:57:31 ildikov anyway, if the shareable flag cannot appear in the xml by accident for a non-multiattach volume, then good
15:57:43 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: create vGPU for instance https://review.openstack.org/528832
15:58:29 mriedem i'm not entirely sure how the various retype and volume migration stuff works on the cinder side
15:58:39 mriedem retype is like a resize in nova right? new flavor/volume type
15:58:53 mriedem volume migration is not a change in volume type, but it migrates the volume from one backend to another of the same type?
15:59:30 mriedem anywho, meeting time
15:59:36 ildikov yeah, I guess you're right, I always confuse myself with the different types of swap...
16:10:28 bauzas mdbooth: updated based on your comments
16:18:10 openstackgerrit Matt Riedemann proposed openstack/nova master: Address nits in change I7e01f95d7173d9217f76e838b3ea71555151ef56 https://review.openstack.org/532898
16:27:18 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Amend the migration paging spec for uuid in server migrations response https://review.openstack.org/532904
16:28:14 mriedem nova-multiattach job failed with NODE_FAILURE in the experimental queue :(
16:28:18 mdbooth bauzas: Hey, can you try a couple of things on your mdev box and document the results: create more mdevs than permitted, and create an mdev with an invalid name.
16:28:41 bauzas mdbooth: I'm just trying the former :)
16:29:55 mdbooth bauzas: The BFL around that function is fine by me. How do you plan to address all the other places which call _get_guest_xml?
16:31:30 ildikov mriedem: sadness :(
16:36:19 mnaser from what i understand, once an instance is scheduled in a cell, it will forever remain in that cell (rebuilds, live migrations, etc?)
16:36:27 openstackgerrit Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
16:36:27 openstackgerrit Eric Fried proposed openstack/nova master: Track provider traits in report client https://review.openstack.org/521686
16:36:28 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
16:36:28 openstackgerrit Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
16:36:29 openstackgerrit Eric Fried proposed openstack/nova master: Raise conflict exception on RP create 409 https://review.openstack.org/532563
16:36:29 openstackgerrit Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
16:36:30 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098
16:36:30 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564
16:36:31 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
16:36:31 openstackgerrit Eric Fried proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
16:36:32 openstackgerrit Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
16:36:59 bauzas mdbooth: yup, in separate change
16:37:08 efried gibi If you're still around, would you please re+W https://review.openstack.org/521686 (just rebased)
16:37:17 bauzas mdbooth: oh shit, I forgot to amend the relnote telling that limitation
16:37:35 bauzas (basically, don't touch your instance for the moment once it's up)
16:37:53 mdbooth bauzas: Commented.
16:37:55 efried mgoddard Un-WIP'd SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564 -- see how ya like it.
16:38:07 efried mgoddard And maybe let's talk about peeling it out of that series so you can make use of it.
16:38:09 mriedem need a couple of cores to review the 2.57 novaclient change https://review.openstack.org/#/c/528128/
16:38:14 mriedem and 2.58 above it
16:38:17 mriedem and 2.59 is approved
16:38:24 mriedem client freeze is in 2 weeks
16:38:40 maciejjozefczyk mriedem: about https://review.openstack.org/#/c/520024/
16:38:44 maciejjozefczyk mriedem: found :)
16:39:35 mdbooth bauzas: Is it really useful to land in that state? The code is pretty cleanly separated. It's kinda annoying that the libvirt folks half-landed mdev for eg, and now we can't tell which version we're supposed to required.
16:39:52 maciejjozefczyk mriedem: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py?utf8=✓#L613
16:40:07 bauzas mriedem: ack, top prio list of reviews, starred
16:40:42 bauzas API microversion client side changes are like more important than feature prios to me
16:41:03 mriedem maciejjozefczyk: so it overwrites the ComputeNode allocation ratios which are set in code, to the self allocation ratios set in the RT via the config options?
16:41:47 mriedem maciejjozefczyk: i'm guessing that's in there in case the operator changed the configs and restarted the service
16:42:00 maciejjozefczyk mriedem: yes
16:42:13 maciejjozefczyk mriedem: if not 0; then rewrite ;P ?
16:42:13 mriedem but maybe https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py?utf8=%E2%9C%93#L148 should match what's in the compute node object...
16:42:19 mriedem CONF.cpu_allocation_ratio or 16.0
16:42:21 mriedem something like that
16:42:32 mriedem maciejjozefczyk: or that
16:42:56 mriedem it's definitely shitty that we have multiple places writing this value into the ocmpute node record
16:43:04 maciejjozefczyk mriedem: so.. should i create other bug and then fix it?
16:43:07 mriedem as evidenced by the fact it took 3 of us 3 hours yesterday to figure this out
16:43:11 mriedem maciejjozefczyk: sure
16:43:11 maciejjozefczyk mriedem: maybe move it to common
16:43:30 mriedem i think we have to leave what's in the compute node object
16:43:37 mriedem but the RT stuff definitely isn't obvious
16:44:55 mriedem fyi to anyone that's interested in what's going on with the gate http://grafana.openstack.org/dashboard/db/zuul-status
16:45:02 mriedem executors are maxed out so throughput is down
16:45:14 mriedem recheck grind is also killing things
16:45:31 mriedem so if you have a patch queued up in zuul, no need to recheck it
16:45:52 mriedem add the change number to http://status.openstack.org/zuul/ if you want to see if it's queue
16:45:54 mriedem *queued
16:46:12 mriedem or use https://github.com/openstack/gerrit-dash-creator
16:47:35 bauzas mdbooth: very interesting, I'm trying to allocate 2 vGPUs on a single VM
16:47:45 bauzas libvirt fails miserably
16:48:02 bauzas I guess because of the nvidia driver
16:48:36 mdbooth bauzas: Other fun things: allocate 1 vgpu to 2 vms. Create an mdev of each of 2 different types.
16:49:01 bauzas mdbooth: my code prevents that
16:49:01 mdbooth bauzas: It would be awesome to document all these failure modes somewhere in a code comment. Maybe the privsep function?
16:49:12 bauzas mdbooth: we only support one type
16:49:13 mdbooth Yeah, I know.
16:49:22 bauzas and that's documented in the relnote
16:49:46 mdbooth bauzas: Right, but I'm just thinking it's interesting to understand our failure modes, and most people don't have the hardware to hand to test it.
16:49:58 bauzas for the multi-assignment of the same mediated device, that should also be in theory avoided by my code, except if bugs
16:50:02 mdbooth Will help reviewers/maintainers, for eg
16:50:21 bauzas mdbooth: I mean, what would you like to see ?
16:50:43 bauzas mdbooth: I can try to change the conf opt
16:50:45 mdbooth So do we see a failure on creating the mdev?
16:50:54 mdbooth Or subsequently when we try to use it?

Earlier   Later