| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-26 | |||
| 14:08:18 | gibi | sdague: that would be nice | |
| 14:08:22 | dansmith | mriedem: meh | |
| 14:08:50 | mriedem | meh?! | |
| 14:08:55 | mriedem | it's wishlist, sure | |
| 14:09:02 | dansmith | MEH | |
| 14:09:05 | mriedem | gdi | |
| 14:09:13 | gibi | sdague, mriedem: we are at the start of the cycle so I'm brave enough to try to remove the whole locking code and see what happens | |
| 14:09:48 | mriedem | dansmith: oh yeah, also came across this last night https://review.openstack.org/#/c/502236/ | |
| 14:09:49 | mriedem | derp | |
| 14:11:10 | dansmith | ack yeah | |
| 14:11:48 | mriedem | gibi: you can be brave locally to start :) | |
| 14:11:53 | sdague | gibi: yeh, well we should at least get the test_rpc under timeout control, regardless of the rest of it | |
| 14:13:10 | gibi | mriedem: I can definitly do that | |
| 14:13:20 | avolkov | mriedem: ack | |
| 14:13:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make TestRPC inherit from the base nova TestCase https://review.openstack.org/507239 | |
| 14:14:11 | mriedem | ^ removes the lock thing | |
| 14:14:15 | mriedem | so we'll have the timeout fixture | |
| 14:15:29 | gibi | sdague: agree. I found one more place where we use the testtools.TestCase directly. I left a comment in your review | |
| 14:15:46 | sdague | gibi: in the fixtures? | |
| 14:16:00 | gibi | sdague: here https://github.com/openstack/nova/blob/62c4535a85f7d37f1c9da1e8a747f25ec63dc785/nova/tests/unit/api/openstack/test_requestlog.py#L38 | |
| 14:16:18 | sdague | ah, cool, good catch | |
| 14:16:39 | mriedem | i thought ^ was intentional | |
| 14:16:45 | mriedem | for the placement split or something | |
| 14:17:06 | gibi | sdague: I think fixtures are OK to derive from testtools.TestCase as we use fixtures like mixins | |
| 14:17:23 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Fix --max-count handling for nova-manage cell_v2 map_instances https://review.openstack.org/507552 | |
| 14:17:23 | sdague | gibi: yeh, some of the more advanced ones should see the timeout | |
| 14:17:29 | sdague | but I think that's follow on | |
| 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 | |