| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-26 | |||
| 14:17:33 | sdague | mriedem: it's a good question | |
| 14:18:30 | gibi | sdague, mriedem: at least this request_log test should be also under timeout control | |
| 14:18:36 | sdague | gibi: so, I'd actually rather handle nova/tests/unit/api/openstack/test_requestlog.py as follow on, because those actually do most of the fixture setup (except the timeout one) manually | |
| 14:18:44 | sdague | so it's going to be a bit more extensive change there | |
| 14:18:52 | sdague | I do agree that we should get that under timeout control | |
| 14:19:02 | sdague | but test_rpc is failing a lot now | |
| 14:19:16 | gibi | sdague: I'm OK with that approach. Then I'm +2 on your patch introducing BasicTestCase | |
| 14:19:17 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Fix --max-count handling for nova-manage cell_v2 map_instances https://review.openstack.org/507556 | |
| 14:20:00 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/newton: Fix --max-count handling for nova-manage cell_v2 map_instances https://review.openstack.org/507557 | |
| 14:20:57 | manasm | bauzas: here is the exception I saw with the resize -2017-09-22 07:49:16.377 13573 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/scheduler/utils.py", line 567, in setup_instance_group | |
| 14:20:58 | manasm | 2017-09-22 07:49:16.377 13573 ERROR nova.api.openstack.extensions request_spec.instance_group.hosts = list(group_info.hosts) | |
| 14:20:59 | manasm | 2017-09-22 07:49:16.377 13573 ERROR nova.api.openstack.extensions | |
| 14:21:01 | manasm | 2017-09-22 07:49:16.377 13573 ERROR nova.api.openstack.extensions AttributeError: 'NoneType' object has no attribute 'hosts' | |
| 14:21:03 | manasm | 2017-09-22 07:49:16.377 13573 ERROR nova.api.openstack.extensions | |
| 14:21:07 | jaypipes | mriedem, dansmith, gibi, sdague, bauzas: any of you noticed weird glitches in the new Gerrit web UI where the screen blinks and flashes when you open up long in-page comments? | |
| 14:21:18 | dansmith | no | |
| 14:21:23 | jaypipes | hmmm | |
| 14:21:32 | gibi | at least not yet | |
| 14:21:37 | jaypipes | it's a good thing I don't have Tourettes. | |
| 14:21:57 | jaypipes | or epilepsy I gues | |
| 14:22:49 | jaypipes | efried: around? want to chat about "trait inheritance"... | |
| 14:23:01 | efried | jaypipes I thought you'd never ask :* | |
| 14:23:06 | jaypipes | lol | |
| 14:23:18 | efried | jaypipes I have also experienced the gerrit UI glitchiness. | |
| 14:23:31 | jaypipes | efried: oh, good (or bad...) at least I'm not the only one | |
| 14:23:46 | efried | So yeah, trait inheritance... | |
| 14:24:10 | efried | Did you see my long-winded comment with example based on (or at least attributed to) your response to my response etc. etc.? | |
| 14:24:26 | jaypipes | efried: yeah, so it's absolutely correct that whatever is constructing the provider tree will need to attach traits at the appropriate provider leel | |
| 14:24:27 | jaypipes | level | |
| 14:24:55 | efried | Yuh. And the spec (ultimately the docs) will need to dictate what level(s) is/are "appropriate". | |
| 14:25:12 | efried | Because the code is gonna hafta do some work to percolate 'em around, if that's supported. | |
| 14:25:56 | jaypipes | efried: no, there's no percolating around... | |
| 14:26:27 | sdague | jaypipes: url? | |
| 14:26:42 | efried | jaypipes sdague Talking about this 'un: https://review.openstack.org/#/c/497713/6/specs/queens/approved/add-trait-support-in-allocation-candidates.rst@42 | |
| 14:27:00 | jaypipes | sdague: are you talking about the gerrit thing or the nested providers thing? :) | |
| 14:27:06 | efried | (oh, sdague unless you were... yeah...) | |
| 14:27:09 | sdague | jaypipes: gerrit thing | |
| 14:27:34 | jaypipes | sdague: mostly seen it happen on specs with long (>8 replies) inline comment "threads" | |
| 14:27:44 | jaypipes | sdague: next time it happens I'll ping you a link | |
| 14:27:49 | efried | For me, the gerrit thing is intermittent, happens when I'm expanding comments on a long page with lots of comments | |
| 14:27:53 | jaypipes | ya | |
| 14:28:06 | sdague | gerrit sends back a lot of ajax calls to get all those bits | |
| 14:28:16 | efried | But not reproducible, cause I pop up to the review and back down and do the same thing and it doesn't happen the second time. | |
| 14:28:24 | sdague | if it's gone slow, or your connection is weird, it might take a while for them to pile in and render | |
| 14:28:43 | efried | I don't think it's ajax. Seems like client-side js focus() calls. | |
| 14:28:47 | jaypipes | sdague: nah, it's more like a loop in the UI that happens. | |
| 14:28:55 | jaypipes | sdague: ya, what efried said :) | |
| 14:29:06 | sdague | jaypipes: well, web console in chrome might help explain things | |
| 14:29:22 | jaypipes | like it can't decide which comment to align to the top of the screen canvas | |
| 14:29:35 | jaypipes | sdague: when it happens again I'll ping ya | |
| 14:29:41 | efried | I noticed focus bugs before the upgrade too, usually when composing a comment on a long page, it would jump around (shoving my comment box off the visible screen) | |
| 14:29:56 | jaypipes | efried: yeah, that's happened for a long time | |
| 14:30:46 | sdague | note, we also inject a lot of our own custom client side js to do the CI rollup, so it's entirely possible that is related to the issue | |
| 14:31:31 | sdague | regardless seeing if you can get an inspect console on the issue would be handy | |
| 14:32:20 | jaypipes | sdague: will do | |
| 14:32:36 | jaypipes | efried: you want me to response here or on the review? | |
| 14:32:38 | efried | jaypipes Okay, so in the example in the comment I linked above: does that work as stated? | |
| 14:33:05 | efried | jaypipes Wouldn't mind discussing a bit, then putting a summary in the review. Just to make sure we're talking about the same thing, save time. | |
| 14:33:30 | jaypipes | efried: your statement there, right after "How about" is spot on. | |
| 14:34:03 | jaypipes | efried: this is excellent: | |
| 14:34:04 | jaypipes | "With nested resource providers, traits defined on a parent RP are assumed to belong to all its child (descendant) RPs. However, traits defined on a child RP do not apply to the parent (ancestor) RPs. There is no implied sharing of traits within aggregates." | |
| 14:34:46 | jaypipes | efried: even more explicit would be pointing out that aggregates don't actually have *any* traits associated to themselves at all (there's no aggregate_metadata table like there is in Nova) | |
| 14:34:55 | jaypipes | efried: only resource providers have traits associated with them. | |
| 14:35:18 | efried | Rightright, point being that RP1 doesn't inherit any traits from RP2 just because they're in the same aggregate. | |
| 14:35:59 | jaypipes | efried: correct. it's worth spelling that out. aggregates are only grouping mechanisms, nothing more. | |
| 14:36:31 | efried | jaypipes Okay, cool. So traits are inherited in NRPs, downwards but not upwards. And the example below that sentence would work as described. I guess the implementation details aren't important, but I'm a bit curious how it would work if you didn't actually internally copy the traits from the parent to its children. | |
| 14:37:37 | jaypipes | efried: don't worry about the implementation details of the queries at this point. | |
| 14:38:43 | efried | jaypipes Roger that. So okay, it sounds like we're in agreement. Thanks for the talk. | |
| 14:39:50 | jaypipes | efried: just typing up in the review... gimme a few | |
| 14:39:59 | efried | ++ | |
| 14:43:51 | jaypipes | alex_xu: not sure if you're still up, but if you can make the few requested changes on https://review.openstack.org/#/c/497713/ from me and efried, I'm ready to +2 that one. | |
| 14:43:51 | ratailor | sdague, you around ? | |
| 14:44:04 | openstackgerrit | Matthew Booth proposed openstack/nova master: Make etree.tostring() emit unicode everywhere https://review.openstack.org/507488 | |
| 14:44:05 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Don't VIR_MIGRATE_NON_SHARED_INC without migrate_disks https://review.openstack.org/507202 | |
| 14:44:38 | ratailor | sdague could you have a look at https://review.openstack.org/#/c/504885/ | |
| 14:46:12 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Moving more utils to ServerResourceAllocationTestBase https://review.openstack.org/499539 | |
| 14:46:13 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: factor out compute service start in ServerMovingTest https://review.openstack.org/503037 | |
| 14:46:13 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test resource allocation during soft delete https://review.openstack.org/495159 | |
| 14:46:57 | openstackgerrit | Moshe Levi proposed openstack/nova master: Don't overwrite binding-profile https://review.openstack.org/505613 | |
| 14:48:05 | gibi | sdague: I'm looking at https://review.openstack.org/#/c/505673 (qemu 2.10 support). Do we have a way to unit test the change you made in the libvirt/driver.py ? | |
| 14:52:02 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Change 'InstancePCIRequest' spec field https://review.openstack.org/449257 | |
| 14:52:14 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/507481 | |
| 14:54:59 | gibi | if somebody want some easy patches to review then I'd like to suggest a test improvement series starts https://review.openstack.org/#/c/499539 and mriedem already +2 on it. | |
| 14:55:58 | bauzas | jaypipes: I did noticed | |
| 14:56:05 | bauzas | jaypipes: Firefox FTW | |
| 14:56:19 | jaypipes | bauzas: I'm on firefox... | |
| 14:56:31 | bauzas | when I say FTW, it's sarcastic | |
| 14:56:44 | bauzas | so yeah, I'm hitted too | |
| 14:57:09 | bauzas | I suspected a French regulation cause, but looks like it's not :p | |
| 14:58:07 | mriedem | gibi: good point, there is no unit test coverage of the libvirt driver change or the images change to use the new flag | |
| 14:58:14 | mriedem | gibi: -1 that sonofa | |
| 14:59:21 | gibi | mriedem: I think the image part is covered by https://review.openstack.org/#/c/505673/5/nova/tests/unit/virt/libvirt/test_utils.py@181 | |
| 15:00:31 | bauzas | mriedem: not sure I love assigning a new module attribute for the QEMU version, but I guess it's probably the only easy way | |
| 15:00:51 | bauzas | mriedem: I'm thinking of cases where you don't reload your module and you're doomed | |
| 15:00:57 | mriedem | oh i see | |
| 15:01:21 | bauzas | but I guess upgrading qemu would be part of a nova minor upgrade as well, so that would require restarting n-cpu as well | |
| 15:01:33 | mriedem | bauzas: jamespage went an alternate route where the version was passed down through the many plumbing layers, and it was quickly unmanageable | |
| 15:01:53 | mriedem | another alternative is handling the error, parsing the output and retrying with the flag, which also sucks | |
| 15:01:56 | bauzas | mriedem: yeah, I was thinking the image module wasn't written like that, but unfortunately it is | |
| 15:02:06 | bauzas | it's just an helper module | |