| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-28 | |||
| 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 | |
| 16:27:33 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: deprecate the config for image handler class path https://review.openstack.org/497201 | |
| 16:27:34 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: define a new image handler to use vdi streaming https://review.openstack.org/486475 | |
| 16:54:42 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: generation in provider aggregate APIs https://review.openstack.org/548249 | |
| 16:54:52 | efried | cdent: ^ | |
| 16:55:09 | cdent | noted | |
| 16:55:19 | efried | though I admit I did not build *everything* locally. | |
| 16:58:20 | efried | cdent: Oho, this actually does break an existing test that's relatively well-behaved. | |
| 16:58:44 | efried | so, I wonder if we want to reconsider our "always increment generation" thought. | |
| 16:59:07 | efried | test_report_client L361 gets a gen conflict. | |
| 17:26:12 | openstackgerrit | Merged openstack/nova stable/pike: Fix possible TypeError in VIF.fixed_ips https://review.openstack.org/531745 | |
| 17:26:19 | openstackgerrit | Merged openstack/nova master: libvirt: mask InjectionInfo.admin_pass https://review.openstack.org/526772 | |
| 17:54:04 | openstackgerrit | Merged openstack/nova stable/pike: Proper error handling by _ensure_resource_provider https://review.openstack.org/524618 | |
| 18:19:59 | openstackgerrit | Merged openstack/nova stable/pike: Do not attempt volume swap when guest is stopped/suspended https://review.openstack.org/533733 | |
| 18:23:13 | openstackgerrit | John Griffith proposed openstack/nova master: Check for multiattach before nuking connections https://review.openstack.org/548427 | |
| 18:29:08 | openstackgerrit | Merged openstack/nova stable/pike: Refine waiting for vif plug events during _hard_reboot https://review.openstack.org/542748 | |
| 19:54:56 | openstackgerrit | Merged openstack/nova master: Stop using mox in api/openstack/fakes.py https://review.openstack.org/325759 | |
| 20:39:02 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Refactor WSGI apps and utils to limit imports https://review.openstack.org/533797 | |
| 20:39:02 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] use simple FaultWrapper https://review.openstack.org/533752 | |
| 20:45:21 | openstackgerrit | Merged openstack/nova master: Clarify the help text for [scheduler]periodic_task_interval https://review.openstack.org/544015 | |
| 20:45:30 | openstackgerrit | Merged openstack/nova master: Remove the deprecated scheduler_driver_task_period option https://review.openstack.org/531413 | |
| 22:49:46 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: generation in provider aggregate APIs https://review.openstack.org/548249 | |