Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-28
11:05:15 mnaser If that’s too much feel free to discuss it
11:05:20 mriedem ok we're still ratholing on something else
11:05:33 mnaser I’m figuring out something for my throat heh
11:16:32 openstackgerrit Claudiu Belu proposed openstack/nova master: conductor: add live_resize task https://review.openstack.org/248579
11:16:32 openstackgerrit Claudiu Belu proposed openstack/nova master: compute: Adds instance live-resize https://review.openstack.org/248581
11:16:33 openstackgerrit Claudiu Belu proposed openstack/nova master: API: Adds instance live-resize https://review.openstack.org/184584
11:33:07 openstackgerrit sean mooney proposed openstack/nova-specs master: Reintroduced nic feature based scheduling for rocky https://review.openstack.org/545951
11:58:36 openstackgerrit Thomas Bechtold proposed openstack/nova master: Allow 'network' in RequestContext service_catalog https://review.openstack.org/548572
12:08:46 openstackgerrit Matt Riedemann proposed openstack/nova master: Stop using mox in api/openstack/fakes.py https://review.openstack.org/325759
12:32:22 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: compute: Cleans up allocations after failed resize https://review.openstack.org/548584
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/

Earlier   Later