| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-13 | |||
| 11:32:28 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290 | |
| 11:37:11 | stephenfin | sean-k-mooney: When you're about, could you have a look at that to make sure the "problem description" section actually makes sense now? Still trying to configure a machine to evaluate this myself https://review.openstack.org/#/c/541290/2/specs/rocky/approved/numa-aware-vswitches.rst | |
| 11:49:58 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova-specs master: Enable NUMA Features for Libvirt/QEMU Driver https://review.openstack.org/533077 | |
| 11:50:45 | openstackgerrit | Merged openstack/nova master: Move the nova-next job in-tree and update it https://review.openstack.org/541474 | |
| 13:54:54 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Test websocketproxy with TLS in the nova-next job https://review.openstack.org/513160 | |
| 14:00:21 | esberglu | #startmeeting powervm_driver_meeting | |
| 14:00:22 | openstack | Meeting started Tue Feb 13 14:00:21 2018 UTC and is due to finish in 60 minutes. The chair is esberglu. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 14:00:23 | openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 14:00:25 | openstack | The meeting name has been set to 'powervm_driver_meeting' | |
| 14:00:44 | esberglu | #topic In-tree Driver | |
| 14:01:15 | esberglu | #endmeeting | |
| 14:01:18 | openstack | Meeting ended Tue Feb 13 14:01:15 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 14:01:19 | openstack | Minutes: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2018/powervm_driver_meeting.2018-02-13-14.00.html | |
| 14:01:20 | openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2018/powervm_driver_meeting.2018-02-13-14.00.txt | |
| 14:01:21 | openstack | Log: http://eavesdrop.openstack.org/meetings/powervm_driver_meeting/2018/powervm_driver_meeting.2018-02-13-14.00.log.html | |
| 14:01:24 | esberglu | Sorry thought I was in a different channel | |
| 14:19:10 | bauzas | mriedem: some possible race when trying to delete a BuildRequest instance https://bugs.launchpad.net/nova/+bug/1749167 | |
| 14:19:11 | openstack | Launchpad bug 1749167 in OpenStack Compute (nova) "nova show can not get an instance information, and this instance can be queried from nova list." [Undecided,New] | |
| 14:19:20 | bauzas | dansmith: when you're up, see above $ | |
| 14:19:54 | bauzas | what I'm confused is that I can see a "too many connections'" SQL exception | |
| 14:26:42 | openstackgerrit | Jiri Suchomel proposed openstack/nova master: Retry few times when creating the initial connection to libvirtd. https://review.openstack.org/416928 | |
| 14:34:06 | dansmith | bauzas: why is that confusing? I think it means there are too many connections :) | |
| 14:34:33 | dansmith | I can also imagine that we hit that while trying to do the BR->RS->IM dance and thus it's in the cell and not mapped | |
| 14:35:16 | bauzas | dansmith: yeah, I actually provided a comment | |
| 14:35:23 | dansmith | I saw :) | |
| 14:35:27 | bauzas | it impacted the scheduler call | |
| 14:35:36 | dansmith | and probably other things | |
| 14:35:51 | bauzas | so, yeah, let's ask to reproduce and if not, close it | |
| 14:36:11 | bauzas | dansmith: unrelated, other evacuate thing https://bugs.launchpad.net/nova/+bug/1745977 | |
| 14:36:12 | openstack | Launchpad bug 1745977 in OpenStack Compute (nova) "When source compute service up, will not destroy and clean up those instances which be evacuated then be deleted." [Undecided,New] | |
| 14:38:35 | dansmith | okay | |
| 14:57:47 | mriedem | lyarwood: want to get this pike backport? https://review.openstack.org/#/c/537811/ | |
| 14:57:54 | mriedem | i'm going to push a pike release today | |
| 14:58:41 | mriedem | dansmith: can you get this one? https://review.openstack.org/#/c/541036/ | |
| 14:58:55 | lyarwood | mriedem: ack looking | |
| 14:59:37 | mriedem | i can't remember if you guys needed this for product either https://review.openstack.org/#/c/539003/ | |
| 15:00:43 | dansmith | erm, not sure I've looked at that one in depth, we should ask her when she's around | |
| 15:02:46 | mriedem | lyarwood: i'm not sure about this one https://review.openstack.org/#/c/533733/ - i suppose it's ok since it fails fast in the api rather than silently on the compute, | |
| 15:02:56 | mriedem | the problem with swap volume is that i don't think anyone uses it directly, | |
| 15:03:07 | mriedem | it happens as a result of a cinder volume retype or migration | |
| 15:03:30 | lyarwood | mriedem: right but wouldn't this result in a cleaner failure in that case as well? | |
| 15:03:32 | mriedem | so really, the doc updates should be in the cinder api-ref for retype saying that you can't retype an attached volume where the server instance is in one of those states | |
| 15:04:03 | mriedem | i don't know if/how cinder handles a 409 from swap volume, and if it rolls back the retype | |
| 15:04:31 | lyarwood | mriedem: that was an assumption on my part, we'd actually return a 409 to cinder now at least. | |
| 15:04:36 | mriedem | it is better to get a 409 though so cinder at least has a chance to do some kind of rollback | |
| 15:06:25 | mriedem | looks like cinder will delete the new volume (for a retype), and then set the old volume.migration_status='error' | |
| 15:06:49 | mriedem | and set the old volume status back to in-use | |
| 15:06:54 | mriedem | (i think) | |
| 15:10:14 | mriedem | lyarwood: ok +2 on that one; want to get https://review.openstack.org/#/c/541036/ and then i'll cut the release? | |
| 15:11:47 | lyarwood | mriedem: yup will do, thanks | |
| 15:23:03 | mriedem | lyarwood: this is re-introducing a regression from queens https://review.openstack.org/#/c/543569/ | |
| 15:23:06 | mriedem | i'm pretty sure anyway | |
| 15:24:13 | lyarwood | mriedem: How so? We also block swap_volume for encrypted volumes when using native LUKS in >=Queens | |
| 15:24:26 | mriedem | lyarwood: https://github.com/openstack/nova/commit/cafe3d066ef7021c18961d4b239a10f61db23f2d#diff-f4019782d93a196a0d026479e6aa61b1 | |
| 15:24:41 | mriedem | you're not backporting that regression fix, introduced by the native luks support patch | |
| 15:24:46 | mriedem | that broke several cinder backends | |
| 15:25:16 | openstackgerrit | Boris Bobrov proposed openstack/python-novaclient stable/queens: Fix listing of instances above API max_limit https://review.openstack.org/543968 | |
| 15:26:13 | lyarwood | mriedem: crap, yeah my bad | |
| 15:31:52 | mriedem | stephenfin: you would probably enjoy the honors here https://review.openstack.org/#/c/513160/ | |
| 15:31:58 | mriedem | nova-next job + tls proxy enabled | |
| 15:32:14 | stephenfin | mriedem: Ooh, snazzy | |
| 15:32:57 | openstackgerrit | Dan Smith proposed openstack/nova master: Lazy-load instance attributes with read_deleted=yes https://review.openstack.org/543970 | |
| 15:33:11 | mriedem | i think once we drop the legacy nova-next job that's defined in openstack-zuul-jobs, we should look at making nova-next (defined in tree) voting and gating | |
| 15:33:25 | mriedem | and we should probably also make it run with py3 | |
| 15:33:29 | openstackgerrit | Claudiu Belu proposed openstack/nova master: compute: Makes the resize_instance RPC call synchronous https://review.openstack.org/543971 | |
| 15:33:33 | cdent | \o/ | |
| 15:33:51 | mriedem | claudiub: re your allocation + resize delete thing, did you report a bug for that? | |
| 15:33:55 | mriedem | if not, can you? | |
| 15:34:18 | claudiub | I did. I just sent a patch for it as well | |
| 15:34:20 | claudiub | ^ | |
| 15:34:40 | claudiub | basically, the Except branch in ComputeManager's prep_resize is never executed. | |
| 15:34:45 | mriedem | claudiub: i don't think that's the kind of fix we want | |
| 15:35:00 | claudiub | in which the allocations gets cleaned up | |
| 15:35:03 | mriedem | we likely need to handle the allocation cleanup in resize_instance | |
| 15:35:31 | stephenfin | mriedem: Both the commit message and comment in 'nova-next/run.yaml' say the 'tls-proxy' service is enabled when it isn't. If you want to drop that, I can +W | |
| 15:35:43 | stephenfin | Or vice versa. It's confusing otherwise :) | |
| 15:36:00 | claudiub | that could work too | |
| 15:36:59 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Test websocketproxy with TLS in the nova-next job https://review.openstack.org/513160 | |
| 15:37:21 | claudiub | we might have to do the rescheduling there too, then. | |
| 15:37:21 | mriedem | stephenfin: done | |
| 15:37:40 | stephenfin | mriedem: likewise | |
| 15:37:43 | mriedem | claudiub: if resize_instance fails, we're dead | |
| 15:38:36 | claudiub | what do you mean? | |
| 15:38:53 | claudiub | you mean that the resize operation should fail, and be put in error state? | |
| 15:38:54 | mriedem | i don't think we need to try and make every part of a resize reschedulable | |
| 15:38:56 | mriedem | yes | |
| 15:40:08 | mriedem | changing the rpc cast to call might fix this issue, but likely introduces an rpc messaging timeout problem | |
| 15:40:15 | mriedem | if resize_instance takes >1 minute | |
| 15:40:17 | claudiub | well, not necessarely always. for example, if an InstanceFaultRollback is raised by the driver (at least in our scenario - if the new flavor's disk is smaller than the original), then the resize didn't happen, and the instance will be put back into Running state | |
| 15:40:37 | claudiub | hm, I see. | |
| 15:42:50 | mriedem | i see that the libvirt driver's migrate_disk_and_power_off method, called from resize_instance, is doing some checks like if you're trying to resize the disk down or if you're using lvm, it fails, | |
| 15:42:52 | jaypipes | dims: https://twitter.com/jaypipes/status/963437624852668419 | |
| 15:42:57 | mriedem | in that case we'd fail and not reschedule | |
| 15:43:06 | mriedem | but in those cases, we don't want to reschedule | |
| 15:43:26 | claudiub | fair enough | |
| 15:43:32 | dims | jaypipes, y i was reading all about it yesterday ... :( | |
| 15:43:56 | claudiub | well then, I'll send another PS. | |
| 15:48:13 | mriedem | claudiub: you can maybe build a functional test similar to test_resize_to_same_host_prep_resize_fails | |
| 15:48:25 | mriedem | where resize_instance fails and we make sure to cleanup allocations created by the scheduler for the destination host | |
| 15:49:50 | claudiub | will do | |