| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-28 | |||
| 13:24:15 | toabctl | melwitt, mriedem could you have a look at https://review.openstack.org/#/c/548572/ please? I think this is needed for queens (but I don't understand why this is not catched in the gate) | |
| 13:26:59 | takashin | ||
| 13:27:27 | mriedem | efried: ^ | |
| 13:28:13 | melwitt | toabctl: yeah, I was just looking at that earlier. same, don't yet understand how that isn't breaking everything in the gate if it's something required | |
| 13:28:19 | efried | mriedem: Wha? I was offline and eavesdrop hasn't caught up yet. Please paste? | |
| 13:28:29 | mriedem | efried: (1:24:19 PM) toabctl: melwitt, mriedem could you have a look at https://review.openstack.org/#/c/548572/ please? I think this is needed for queens (but I don't understand why this is not catched in the gate) | |
| 13:28:37 | efried | thx | |
| 13:28:56 | mriedem | toabctl: is this a new issue for you in queens? | |
| 13:29:09 | toabctl | mriedem, yes. worked with pike | |
| 13:29:20 | mriedem | toabctl: then it's likely related to https://github.com/openstack/nova/commit/6cde77ebbab85bc8ccd2ab7ad977b1d4af4a13fa | |
| 13:30:47 | mriedem | likely not an issue in the gate b/c of how nova.conf is configured for [neutron] in devstack | |
| 13:31:30 | mriedem | would be useful to compare your config vs http://logs.openstack.org/71/543971/6/check/tempest-full/49cd457/controller/logs/etc/nova/ | |
| 13:33:02 | mriedem | looks ok to me though | |
| 13:33:20 | mriedem | sans the region_name... | |
| 13:33:24 | toabctl | mriedem, I compared already with a recent successful gate run | |
| 13:33:52 | mriedem | does region_name default to RegionOne? | |
| 13:34:01 | toabctl | mriedem, the region is not the problem. having no region is fine. it is really this service_catalog filter. but I don't understand why that is happening now and not in Pike | |
| 13:34:38 | mriedem | #region_name = <None> | |
| 13:34:41 | openstackgerrit | Claudiu Belu proposed openstack/nova master: conductor: add live_resize task https://review.openstack.org/248579 | |
| 13:35:46 | mriedem | toabctl: which version of keystoneauth1 do you have installed? | |
| 13:36:11 | toabctl | mriedem, re region - if not set, it does not matter: https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/access/service_catalog.py#L187 | |
| 13:36:44 | toabctl | mriedem, re keystoneauth1 - it is 3.4.0 | |
| 13:37:03 | toabctl | which is the version from stable/queens upper-constraints | |
| 13:40:31 | toabctl | mriedem, I guess the difference between the gate and my setup is the [neutron]url setting which I have not set | |
| 13:40:49 | toabctl | and the gate does and according to https://github.com/openstack/nova/commit/6cde77ebbab85bc8ccd2ab7ad977b1d4af4a13fa , this is then the "legacy" path | |
| 13:42:05 | mriedem | toabctl: ah yeah, | |
| 13:42:07 | hrw | is nova room still freezer like? | |
| 13:42:23 | mriedem | that's like the admin url endpoint override for neutron in nova.conf, which the ksa adapter stuff was meant to remove | |
| 13:42:51 | efried | toabctl: You're absolutely right, you should not have to set `url` since the commit mentioned by mriedem. | |
| 13:43:07 | efried | toabctl: With that change to context.py, the problem goes away? | |
| 13:43:12 | mriedem | toabctl: can you push a devstack patch that removes this line? https://github.com/openstack-dev/devstack/blob/master/lib/neutron#L309 | |
| 13:43:13 | toabctl | efried, yes | |
| 13:43:25 | toabctl | efried, I did not run tempest yet but I can spawn VMs :) | |
| 13:43:28 | mriedem | toabctl: push that devstack patch, let's see it fail, then add a depends-on to your nova fix and see it pass | |
| 13:43:43 | gryf | hrw, sort of, although I'm in jacket | |
| 13:43:58 | hrw | gryf: thx | |
| 13:50:04 | toabctl | mriedem, efried https://review.openstack.org/#/c/548593/ | |
| 13:50:59 | efried | toabctl: And that will break nova until your other patch merges? | |
| 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 | |