Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-02-28
13:51:13 toabctl efried, that's the theory :)
13:51:27 toabctl and what I have in my local (non-devstack) env
13:51:29 efried sorry, I'm not doing a good job keeping up with the channel.
13:51:43 toabctl efried, np. it's anyway PTG
13:52:26 mriedem toabctl: thanks, will watch that devstack patch
14:02:23 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: compute: Cleans up allocations after failed resize https://review.openstack.org/548584
14:24:55 Roamer` Couple of questions about Nova with Hyper-V on Windows: can I use a Cinder volume (attached via iSCSI?) as a root device for an instance? If yes, can this instance be live-migrated?
14:25:10 lpetrut sure
14:27:02 lpetrut @Roamer` did you encounter any issue with this?
14:27:12 Roamer` lpetrut, so you are saying that I can define Cinder volumes with any kind of storage that supports iSCSI exports, then build a volume-backed instance, and Hyper-V will not copy the data to local storage, and then Nova will find a way to tell Hyper-V to live-migrate it to another controller?
14:27:33 Roamer` lpetrut, to be honest, we haven't tried it yet, but somebody asked us if we can do that
14:28:21 Roamer` lpetrut, the thing is, some coworkers played around a bit with Hyper-V last year (without OpenStack) and had a lot of trouble trying to configure it to consume iSCSI volumes and couldn't get it to live-migrate an iSCSI-based VM... but you're saying that this works with Nova? that's great
14:29:26 lpetrut Roamer` yep, we're using passthrough disks (just like libvirt). I can guess the issues that your colleagues had: you have to make sure that the iSCSI disks are connected to the destination host before requesting the migration
14:29:50 lpetrut and then, we're using "Planned VMs", telling Hyper-V where to look for the iSCSI volumes on the destination host
14:30:39 lpetrut I guess that was the missing piece in your case
14:30:46 Roamer` lpetrut, okay, thanks a whole lot! We'll try it, and I'll be back with more questions if something goes wrong. But thanks for the assurance and for the info!
14:30:59 lpetrut Roamer` any time
14:35:16 kashyap cfriesen__: Hiya, here?
14:35:38 kashyap cfriesen__: When you are — see here, to your comment: https://review.openstack.org/#/c/534384/4
14:36:23 kashyap cfriesen__: Upstream QEMU isn't too eager to add the CPU models for management
14:36:26 kashyap [quote]
14:36:29 kashyap Sane VM management systems would know how to use "-cpu
14:36:31 kashyap Westmere,+pcid" without requiring new CPU model entries in QEMU.
14:36:34 kashyap What's missing in existing management stacks to allow that to
14:36:36 kashyap happen?
14:36:39 kashyap [/quote]
14:36:42 kashyap From here: https://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg02714.html — "[PATCH x86-next v2] target-i386: add PCID flag to Westmere, Sandy Bridge and Ivy Bridge"
14:37:46 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: [WIP] libvirt: Allow to specify granular CPU feature flags https://review.openstack.org/534384
14:45:39 kashyap sean-k-mooney: Since you seem to be interested in this, wonder if you have comments on the functional change above ^?
14:45:58 kashyap ("WIP" because -- need to fix unit tests.)
14:49:15 betherly mriedem: hi! are you at the PTG? having issues with devstack and launching instance that looks like its hitting https://bugs.launchpad.net/nova/+bug/1733933
14:49:17 openstack Launchpad bug 1736946 in OpenStack Compute (nova) ocata "duplicate for #1733933 Conductor: fails to clean up networking resources due to _destroy_build_request CantStartEngineError" [High,In progress] - Assigned to Matt Riedemann (mriedem)
14:52:16 openstackgerrit Thomas Bechtold proposed openstack/nova master: Allow 'network' in RequestContext service_catalog https://review.openstack.org/548572
14:55:13 mriedem betherly: what do you have this set to? https://github.com/openstack-dev/devstack/blob/master/stackrc#L98
14:55:15 mriedem and yes i'm at the ptg
14:55:45 mriedem if ^ is set to superconductor, you can't get back up to the controller from the compute
14:55:54 mriedem if you need to be able to do that for some reason, then you need to set that to 'singleconductor'
14:57:59 betherly mriedem: ye ive just changed to singleconductor and will restack and let you know thanks! weird and slightly concerning though that it works from CLI and not horizon
14:58:43 _ix Hello friends! Any word on release of 16.1.0? Our team is looking forward to the fix referenced here: https://bugs.launchpad.net/nova/+bug/1715569
14:58:44 openstack Launchpad bug 1715569 in OpenStack Compute (nova) pike "Live migration fails with an attached non-bootable Cinder volume (Pike)" [Undecided,Fix committed] - Assigned to sahid (sahid-ferdjaoui)
15:05:34 dansmith cfriesen__: f7c688b8ef88a7390f5b09719a2b3e80368438c0
15:09:28 mriedem betherly: what "works"?
15:09:45 mriedem betherly: are you running a multinode setup?
15:10:27 mriedem _ix: i think we just did a stable/pike release
15:10:30 betherly mriedem: sorry. launching an instance. no so i just have a basic devstack and horizon setup where i needed to launch an instance and then take a snapshot to test something completely different and have hit unexpected issues
15:11:27 mriedem betherly: ok my guess is it's just luck of one server create failing on the compute service, and one passing
15:11:41 mriedem the one that failed on the compute told the conductor service which tried to do some cleanup it shouldn't have
15:11:50 mriedem betherly: also, are you running a recent devstack? like at least queens?
15:13:27 betherly mriedem: queens was just released today. i have been running stable/pike but will setup again with stable/queens later. for now CLI seems to be working so it could be a horizon issue or a performance issue as things seem to be prettyyyy slow and i keep getting 503 errors and needing to re-try before success
15:13:45 betherly mriedem: thanks muchly for all your help. do you mind if i ping you again if i have further issues?
15:16:06 _ix mriedem: I'm not seeing anything for centos 16.1.0, but I'll be patient... or perhaps we should just start the path toward Queens. Thanks!
15:17:09 mriedem betherly: ok was just wondering if you had an old env that doesn't have this fix https://review.openstack.org/#/c/529697/
15:17:34 betherly mriedem: ah i bet thats it
15:17:41 betherly mriedem: perfect thanks!
15:17:53 mriedem _ix: i'm confused, https://review.openstack.org/#/c/541642/ is released in pike 16.1.0
15:18:10 mriedem _ix: i can't speak for centos
15:18:38 mriedem betherly: yw
15:24:03 jianghuaw_ mriedem, for the remaining vGPU work, should we create a new BP in Rocky to track it?
15:24:42 jianghuaw_ The Queens' BP is marked completed, so can be used in commit anymore?
15:25:44 jianghuaw_ s/can/can't/
15:28:28 jianghuaw_ melwitt and bauzas: ^
15:30:04 melwitt yeah, would need a new BP. probably a new spec too which covers the work that will be carried out in rocky, assuming the previous spec only outlined the basic support that we completed in queens
15:30:41 jianghuaw_ all of the thing except NUMA are already in the spec.
15:31:23 jianghuaw_ We only cover basic support is due to some dependence(n-rp and traits allocation) not ready for go in queens.
15:34:03 jianghuaw_ It seems more reasonable to cover NUMA in a separate BP and the remaining items in a spec-less BP?
15:39:59 toabctl mriedem, I also looked at it some min ago. I'll add the depends-on now.
15:41:21 cfriesen__ kashyap: see my latest comment on the review...sent you some examples
15:42:02 kashyap cfriesen__: Hi, just noticed it. IIUC, what you wrote is just for those two specific things, right?
15:42:33 kashyap cfriesen__: I'll respond in more detail on the review soon. Thanks for the comments.
15:43:34 mriedem toabctl: already done
15:45:35 toabctl mriedem, yeah. but I did overwrite your msg. pardon.
15:47:00 jianghuaw_ melwitt, bauzas, mriedem: Created a new BP - https://blueprints.launchpad.net/nova/+spec/vgpu-rocky
15:48:24 openstackgerrit Merged openstack/nova stable/queens: compute: Cleans up allocations after failed resize https://review.openstack.org/548300
15:48:53 melwitt jianghuaw_: okay. so it sounds like it would be re-proposal of the spec to continue the work. would that be correct, mriedem?
15:49:03 melwitt to continue work on vGPU
15:50:17 mriedem the spec was completed in queens,
15:50:21 mriedem so no we wouldn't re-propose it
15:50:32 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Handle spawning error on unshelving https://review.openstack.org/548622
15:50:33 bauzas it's just a placeholder
15:51:11 bauzas in case things require design discussions, I'm fine with either asking or being asked to write a spec
15:51:19 melwitt okay, so would this be specless to continue the work? or a new spec? I thought if the work they want to do this cycle was described in the original spec that it would be a continuation
15:51:24 bauzas but for the moment, I don't see more than just "do the work (c)"
15:51:32 bauzas like we said
15:52:03 jianghuaw_ yeah, just continue the work defined in the spec.
15:52:23 bauzas the NUMA topology reporting as part of update_provider_tree() is even something I see as just an implementation patch, unless someone disagrees
15:52:30 melwitt I don't have an opinion either way. in my experience, if I didn't do all of the implementation described in a spec, I had to re-propose it. I'm fine with this being specless if that's the way to do this
15:53:02 bauzas I think we can use the PTG etherpad as a good track of what's implicitly approved for Rocky
15:53:16 bauzas ie. what wasn't discussed at the PTG requires a spec
15:53:29 mriedem it likely means the spec was too ambitious
15:53:30 bauzas and what was is implicitly accepted as specless BP
15:53:38 mriedem just amend the spec to point out what didn't get done in queens
15:53:52 bauzas good idea
15:54:20 melwitt mriedem: so no new spec needed? just specless to continue?
15:55:25 mriedem sure
15:55:43 melwitt thanks
15:56:04 jianghuaw_ melwitt, mriedem, bauzas thanks.
16:24:13 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: define a new image handler to use vdi streaming https://review.openstack.org/486475
16:24:51 mriedem johnthetubaguy: can you ram this through? https://review.openstack.org/#/c/544015/
16:25:49 openstackgerrit Claudiu Belu proposed openstack/nova master: API: Adds instance live-resize https://review.openstack.org/184584
16:25:49 openstackgerrit Claudiu Belu proposed openstack/nova master: conductor: add live_resize task https://review.openstack.org/248579

Earlier   Later